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Scope 



The present document is step 3 of a three-step approach to describe a generic Handover Interface (HI) for the provision 
of lawful interception from a Network Operator, an Access Provider or a Service Provider (NWO/AP/SvP) to the 
Law Enforcement Agencies (LEAs). The provision of lawful interception is a requirement of national law, which is 
usually mandatory for the operation of any telecommunication service. 
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The present document specifies: 

• the generic flow of information as well as the procedures and information elements, which are applicable to 
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• the network/service specific protocols relating to the provision of lawful interception at the Handover Interface 
(HI), for the following networks/services: 
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The technologies covered in the present document are: GSM, TETRA, GPRS, ISDN, PSTN, fixed NGN (including 
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NOTE: As new networks and/or services are developed, the present document will be expanded as the relevant 
standards become available. 
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latest version of the TS version reflects the latest stable content from ETSI/TC LI. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

access provider: provides a user of some network with access from the user's terminal to that network 

NOTE: This definition applies specifically for the present document. In a particular case, the access provider and 
network operator may be a common commercial entity. 

activation/deactivation of supplementary services: procedures for activation, which is the operation of bringing the 
service into the "ready for invocation" state, and deactivation, which is the complementary action 

(to) buffer: temporary storing of information in case the necessary telecommunication connection to transport 
information to the LEMF is temporarily unavailable 

call: any temporary switched connection capable of transferring information between two or more users of a 
telecommunications system 

NOTE: In this context a user may be a person or a machine. 

CC link: communication channel for HI3 information between a mediation function and a LEMF 

NOTE: It is used for transmission of the Content of Communication (CC). This term refers to circuit switched 
only. 

CC Link IDentifier (CCLID): See definition in clause A.l. 

communication: information transfer according to agreed conventions 

Communication IDentifier (CID): See definition in clause 6. 

Communication Identity Number (CIN): See definition in clause 6. 

communications session: session that consists of either a single self-contained transaction or a series of protocol data 
units that together form a single self-contained communication 
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Content of Communication (CC): information exchanged between two or more users of a telecommunication service, 
excluding Intercept Related Information 

NOTE: This includes information which may, as part of some telecommunication service, be stored by one user 
for subsequent retrieval by another. 

Handover Interface (HI): physical and logical interface across which the interception measures are requested from 
network operator/access provider/service provider, and the results of interception are delivered from a network 
operator/access provider/service provider to a law enforcement monitoring facility 

identity: technical label which may represent the origin or destination of any telecommunications traffic, as a rule 
clearly identified by a physical telecommunication identity number (such as a telephone number) or the logical or 
virtual telecommunication identity number (such as a personal number) which the subscriber can assign to a physical 
access on a case-by-case basis 

information: intelligence or knowledge capable of being represented in forms suitable for communication, storage or 
processing 

NOTE: Information may be represented for example by signs, symbols, pictures or sounds. 

interception: action (based on the law), performed by a network operator/access provider/service provider, of making 
available certain information and providing that information to a law enforcement monitoring facility 

NOTE: In the present document the term interception is not used to describe the action of observing 
communications by a law enforcement agency. 

interception configuration information: information related to the configuration of interception 

interception interface: physical and logical locations within the network operator's/access provider's/service provider's 
telecommunication facilities where access to the Content of Communication and Intercept Related Information is 
provided 

NOTE: The interception interface is not necessarily a single, fixed point. 

interception measure: technical measure which facilitates the interception of telecommunications traffic pursuant to 
the relevant national laws and regulations 

interception subject: person or persons, specified in a lawful authorization, whose telecommunications are to be 
intercepted 

Intercept Related Information (IRI): collection of information or data associated with telecommunication services 
involving the target identity, specifically communication associated information or data (including unsuccessful 
communication attempts), service associated information or data (e.g. service profile management by subscriber) and 
location information 

Internal Interception Function (IIF): point within a network or network element at which the Content of 
Communication and the Intercept Related Information are made available 

Internal Network Interface (INI): network's internal interface between the Internal Interception Function and a 
mediation function 

invocation and operation: describes the action and conditions under which the service is brought into operation 

NOTE 1 : In the case of a lawful interception this may only be on a particular communication. It should be noted 
that when lawful interception is activated, invocation is applicable on all communications (invocation 
takes place either subsequent to or simultaneously with activation). Operation is the procedure which 
occurs once a service has been invoked. 

NOTE 2: The definition is based on ITU-T Recommendation X.882 [37], but has been adapted for the special 
application of lawful interception, instead of supplementary services. 

Law Enforcement Agency (LEA): organization authorized by a lawful authorization based on a national law to 
request interception measures and to receive the results of telecommunications interceptions 

Law Enforcement Monitoring Facility (LEMF): designated as the transmission destination for the results of 
interception relating to a particular interception subject 
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lawful authorization: permission granted to a LEA under certain conditions to intercept specified telecommunications 
and requiring co-operation from a network operator/access provider/service provider 

NOTE: Typically this refers to a warrant or order issued by a lawfully authorized body. 

Lawful Interception (LI): See interception. 

Lawful Interception IDentifier (LIID): See definition in clause 6. 

location information: information relating to the geographic, physical or logical location of an identity relating to an 
interception subject 

Mediation Function (MF): mechanism which passes information between a network operator, an access provider or 
service provider and a Handover Interface, and information between the Internal Network Interface and the Handover 
Interface 

network element: component of the network structure, such as a local exchange, higher order switch or service control 
processor 

Network Element IDentifier (NEID): See definition in clause 6. 

Network IDentifier (NID): See definition in clause 6 . 

NetWork Operator (NWO): operator of a public telecommunications infrastructure which permits the conveyance of 
signals between defined network termination points by wire, by microwave, by optical means or by other 
electromagnetic means 

PSTN/ISDN Emulation Service: mimicks a PSTN/ISDN network from the point of view of legacy terminals (or 
interfaces) by an IP network, through a gateway 

NOTE: All PSTN/ISDN services remain available and identical (i.e. with the same ergonomics); such that end 
users are unaware that they are not connected to a TDM-based PSTN/ISDN. 

PSTN/ISDN Simulation Service: defines the provision of PSTN/ISDN-like services to advanced terminals (IP-phones) 
or IP -interfaces 

NOTE: There is no strict requirement to make all PSTN/ ISDN services available or identical, although end users 
expect to have access to the most popular ones, possibly with different ergonomics. 

Quality of Service (QoS): quality specification of a telecommunications channel, system, virtual channel, 
computer-telecommunications session, etc. 

NOTE: Quality of service may be measured, for example, in terms of signal-to-noise ratio, bit error rate, message 
throughput rate or call blocking probability. 

reliability: probability that a system or service will perform in a satisfactory manner for a given period of time when 
used under specific operating conditions 

result of interception: information relating to a target service, including the Content of Communication and 
Intercept Related Information, which is passed by a network operator, an access provider or a service provider to a law 
enforcement agency 

NOTE: Intercept related information is provided whether or not call activity is taking place. 

service information: information used by the telecommunications infrastructure in the establishment and operation of a 
network related service or services 

NOTE: The information may be established by a network operator, an access provider, a service provider or a 
network user. 

Service Provider (SvP): natural or legal person providing one or more public telecommunications services whose 
provision consists wholly or partly in the transmission and routing of signals on a telecommunications network 

NOTE: A service provider needs not necessarily run his own network. 

sequence number: number that counts individual intercepted protocol data units within a communications session 
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Short Message Service (SMS): service that gives the ability to send character messages to phones 

NOTE: SMS messages can be MO (Mobile Originated) or MT (Mobile Terminated). 

target identity: technical identity (e.g. the interception's subject directory number), which uniquely identifies a target 
of interception 

NOTE: One target may have one or several target identities. 

target service: telecommunications service associated with an interception subject and usually specified in a lawful 
authorization for interception 

NOTE: There may be more than one target service associated with a single interception subject. 

telecommunications: any transfer of signs, signals, writing images, sounds, data or intelligence of any nature 
transmitted in whole or in part by a wire, radio, electromagnetic, photoelectronic or photo-optical system 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

3PTY Three-ParTY service 

AA Abbreviated Address 

AC Alarm Call 

ADMF ADMinistration Function 

AOC Advice Of Charge service 

AP Access Provider 

ASE Application Service Element 

ASN. 1 Abstract Syntax Notation One 

BA DSSl Basic Access 

BC Bearer Capability 

BER Basic Encoding Rules 

BS Basic Service 

CC Content of Communication 

CCBS Completion of Calls to Busy Subscriber 

CCLID CC Link IDentifier 

CCNR Completion of Calls on No Reply 

CD Call Deflection 

CF Call Forwarding 

CFB Call Forwarding on Busy 

CFNR Call Forwarding on No Reply 

CFU Call Forwarding Unconditional 

CGI Cell Global Id 

CID Communication IDentifier 

CIN Communication Identity Number 

CLI Calling Line Identity (Calling Party Number) 

CLIP Calling Line Identification Presentation 

CLIR Calling Line Identification Restriction 

COL connected Line identity (Connected Number) 

COLP connected Line identification Presentation 

COLR connected Line identification Restriction 

CONE CONFerence call, add-on 

CSCF Call Session Control Function 

CUG Closed User Group 

CW Call Waiting 

DDI Direct Dialling In 

DF Delivery Function 

DIV call Diversion services 

DN Directory Number 

DNS Domain Name Service 

DSSl Digital Subscriber Signalling system No.l 

ECT Explicit Call Transfer 



£75/ 



17 



ETSI TS 101 671 V3.1.1 (2007-06) 



FB FallBack procedure 

FDC Fixed Destination Call 

FPH Free PHone 

FTP File Transfer Protocol 

GCID GPRS Charging ID (GGSN address) 

GGSN Gateway GPRS Support Node 

GLIC GPRS LI Correlation 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

GSN GPRS Support Node (SGSN or GGSN) 

GTP GPRS Tunnelling Protocol 

HI Handover Interface 

HIl Handover Interface port 1 (for administrative information) 

HI2 Handover Interface port 2 (for Intercept Related Information) 

HI3 Handover Interface port 3 (for Content of Communication) 

HLC High Layer Compatibility 

HOLD call HOLD service 

IA5 International Alphabet No. 5 

ICB Incoming Call Barring 

ICID IMS Charging ID 

IE Information Element 

IIF Internal Interception Function 

IMEI International Mobile station Equipment Identity 

IMS IP Multimedia Subsystem 

IMSI International Mobile Subscriber Identity 

IN Intelligent Network 

INI Internal Network Interface 

IP Internet Protocol 

IP -CAN IP-Connectivity Access Network 

IRI Intercept Related Information 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

LAC Location Area Code 

LEA Law Enforcement Agency 

LEMF Law Enforcement Monitoring Facility 

LI Lawful Interception 

LIID Lawful Interception IDentifier 

LLC Lower Layer Compatibility 

MAP Mobile Application Part 

MCID Malicious Call IDentification 

MF Mediation Function 

MMC Meet-Me Conference 

MO Mobile Originated 

MS Mobile Station 

MSISDN Mobile Subscriber ISDN Number 

MSN Multiple Subscriber Number 

MT Mobile Terminated 

MWI Message Wait Indication 

NDUB Network Determined User Busy 

NEID Network Element IDentifier 

NID Network IDentifier 

NWO NetWork Operator 

OCB Outgoing Call Barring 

OID Object IDentifiers 

PDP Packet Data Protocol 

PLMN PubUc Land Mobile Network 

PR Partial Rerouting 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RAI Routeing Area Identifier 

ROSE Remote Operation Service Element 
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Rx 


Receive direction 


SAC 


System Area Code 


SCF 


Service Control Function 


SCI 


Subscriber Controlled Input 


SDP 


Session Description Protocol 


SGSN 


Serving GPRS Support Node 


SIP 


Session Initiation Protocol 


SMS 


Short Message Service 


SS No.7 


common channel Signalling System ITU(T) No. 7 


ss 


Supplementary Service 


SSF 


Service Switching Function 


SUB 


SUBaddressing (supplementary service) 


SvP 


Service Provider 


TCP 


Transmission Control Protocol 


TBI 


Terminal Equipment Identity 


TETRA 


TErrestrial Trunked RAdio 


TMR 


Transmission Medium Requirement 


TP 


Terminal Portability 


T-PDU 


Tunnelled PDU 


T 

^x 


Transmit direction 


UDUB 


User Determined User Busy 


UMTS 


Universal Mobile Telecommunication System 


URI 


Uniform Resource Identifier 


URL 


Universal Resource Locator 


UTM 


Universal Transverse Mercator 


UUS 


User-to-User Signalling 


WGS 


World Geodetic System 


wus 


Wake-Up Service 


xGSN 


SGSN or GGSN 



General requirements 



The present document focuses on the Handover Interface related to the provision of information related to LI between a 
network operator, access provider and/or service provider and a Law Enforcement Agency (LEA). 

4.1 Basic principles for the Handover Interface 

The network requirements mentioned in the present document are derived, in part, from the requirements defined in 
ES 201 158 [2]. 

Lawful interception requires functions to be provided in some, or all of, the switching or routing nodes of a 
telecommunications network. 

The specification of the Handover Interface is subdivided into three ports each optimized to the different purposes and 
types of information being exchanged. 

The interface is extensible. 

4.2 Legal requirements 

It shall be possible to select elements from the Handover Interface specification to conform with: 

• national requirements; 

• national law; 

• any law applicable to a specific LEA. 
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As a consequence, the present document shall define, in addition to mandatory requirements, which are always 
applicable, supplementary options, in order to take into account the various influences listed above. See also 
TS 101 331 [1] and ETR 330 [3]. 



4.3 Functional requirements 



A lawful authorization shall describe the kind of information (Intercept Related Information (IRI) or both IRI and 
Content of Communication (CC)) that is required by this LEA, the interception subject, the start and stop time of LI, 
and the addresses of the LEAs for CC and/or IRI and further information. 

A single interception subject may be the subject to interception by different LEAs. It shall be possible strictly to 
separate these interception measures. 

If two targets are communicating with each other, each target is dealt with separately. 



Overview of Handover Interface 



The generic Handover Interface adopts a three-port structure such that administrative information (HIl), Intercept 
Related Information (HI2) and the Content of Communication (HI3) are logically separated. 

Figure 1 shows a block diagram with the relevant entities for Lawful Interception (LI). 

The outer circle represents the NWO/AP/SvP's domain with respect to lawful interception. It contains the network 
internal functions, the Internal Network Interface (INI), the administration function and the mediation functions for IRI 
and CC. The inner circle contains the internal functions of the network (e.g. switching, routing, and handling of the 
communication process). Within the network internal function the results of interception (IRI, CC) are generated in the 
IIF. 

The Internal Interception Functions (IIF) provide the Content of Communication (CC) and the Intercept Related 
Information (IRI), respectively, at the Internal Network Interface INI. For both kinds of information, mediation 
functions may be used, which provide the final representation of the standardized Handover Interfaces at the 
NWO/AP/SvP's domain boundary. 

Within the NWO/AP/SvP's administration centre, the LI related tasks, as received via interface HIl, are translated into 
man machine commands for the NWO/AP/SvP's equipment. 

Depending on the type of network, there might be a need to standardize also some or all of the Internal Network 
Interfaces (INI). Such standards are not in the scope of the present document. 
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NWO/AP/SvP's domain 



LEA 
domain 




I 



■ HIl ^ 



|HI2 



HI3 



I 
I 

I LEMF 

LI handover interface HI 



IIF: internal interception function 
INI:internal network interface 



IHII: administrative information 
HI2: intercept related information 
HG: content of communication 



NOTE 1 : Figure 1 shows only a reference configuration, withi a logical representation of the entities involved in 

lawful interception and does not mandate separate physical entities. 
NOTE 2: The mediation functions may be transparent. 

Figure 1 : Functional block diagram showing Handover Interface HI 

5.1 Handover Interface port 1 (H 11) 

The Handover Interface port 1 shall transport various kinds of administrative information from/to the LEA and the 
organization at the NWO/AP/SvP, which is responsible for LI matters. This interface may be manual or electronic. 

The HIl interface may be crossing borders between countries. This possibility is subject to corresponding international 
laws or agreements. 

A complete separation is required between the administrative part (HIl) and the technical part (INI) of the interface. 
No direct access to the switching function shall be given to the LEMF. Activation, deactivation or modification of an 
interception in the switching function shall only be possible by the NWO/AP/SvP. 

As an option, in direction to the LEA, some HIl related information (e.g. fault reporting) may be delivered directly 
using the HI2 mechanism. As an additional option, in direction to the LEA, some HIl related information may be 
delivered directly, for example, as part of a lawful authorization procedure. 

Further description of HIl is given in clause 7. 
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5.1.1 Manual interface 



If the HIl is designed as a manual interface, it will normally consist of paper documents. The request for lawful 
interception may be sent via letter or via fax to the administration centre of the NWO/AP/SvP. The personnel of the 
administration centre will take the request and activate it in the network element (activation of interception). After the 
interception specified in the lawful authorization is activated, the LEA will be informed, see clause 7. From this point in 
time on, the LEA shall be prepared to receive Intercept Related Information (IRI) via HI2 and Content of 
Communication (CC) via HI3. 

5.1.2 Electronic interface 

An alternative solution may be the electronic transmission of the request for lawful interception. 

The information content shall be such that the authorized personnel of the NWO/AP/SvP is able to map it to the 
information which is required to activate the interception with a minimum of manual translation. This principle reduces 
the probability of errors. 

5.2 Handover Interface port 2 (HI2) 

The Handover Interface port 2 shall transport the IRI from the NWO/AP/SvP's IIF to the LEMF. 

The delivery shall be performed via data communication methods which are suitable for the network infrastructure and 
for the kind and volume of data to be transmitted. 

The delivery can in principle be made via different types of lower communication layers, which should be standard or 
widely used data communication protocols. 

The individual IRI parameters shall be coded using ASN.l and the Basic Encoding Rules (BER). The format of the 
parameter's information content shall be based on existing telecommunication standards, where possible. 

The individual IRI parameters have to be sent to the LEMF at least once (if available). 

The IRI records are transmitted individually, or as an option, IRI records can be aggregated for delivery to the same 
LEA (i.e. in a single delivery interaction). As there are time constraints associated with the delivery of IRI, the use of 
this optional feature is subject to national or regional requirements. As a general principle, IRI records shall be sent 
immediately and shall not be held in the MF/DF in order to use the IRI record aggregation option. 

The IRI records shall contain information available from normal network or service operating procedures. In addition 
the IRI records shall include information for identification and control purposes as specifically required by the HI2 port. 

The IIF is not required to make any attempt to request explicitly extra information which has not already been supplied 
by a signalling system. 

5.3 Handover Interface port 3 (HI3) 

The appropriate form of HI3 depends upon the technology being intercepted, see clause 9. 



Specific identifiers for LI 



Specific identifiers are necessary to identify a target for interception uniquely and to correlate between the data, which 
is conveyed over the different Handover Interfaces (HIl, HI2 and HI3). The identifiers, which apply to all 
communication technologies, are defined in the clauses below. Additional technology specific identifiers are defined in 
related annexes. 
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6.1 Lawful Interception IDentifier (LIID) 

For each target identity related to an interception measure, the authorized NWO/AP/SvP operator shall assign a special 
Lawful Interception IDentifier (LIID), which has been agreed between the LEA and the NWO/AP/SvP. It is used within 
parameters of all HI interface ports. 

Using an indirect identification, pointing to a target identity makes it easier to keep the knowledge about a specific 
interception target limited within the authorized NWO/AP/SvP operators and the handling agents at the LEA. 

The Lawful Interception IDentifier LIID is a component of the CC delivery procedure and of the IRI records. It shall be 
used within any information exchanged at the Handover Interfaces HI2 and HI3 for identification and correlation 
purposes. 

The LIID format shall consist of alphanumeric characters (or digit string for subaddress option, see annex E). It might 
for example, among other information, contain a lawful authorization reference number, and the date, when the lawful 
authorization was issued. 

The authorized NWO/AP/SvP shall either enter a unique LIID for each target identity of the interception subject or as a 
national option a single LIID for multiple target identities all pertaining to the same interception subject. 

EXAMPLE: The interception subject has an ISDN access with three MSNs. The NWO/AP/SvP enters for each 
MSN an own LIID, or optionally enters one LIID for all three MSNs. 

If more than one LEA intercepts the same target identity, there shall be unique LIIDs assigned, relating to each LEA. 



6.2 Communication IDentifier (CID) 



NOTE 1: Was called "Call Identifier" in VL LI of ES 201 671 (see bibliography). It is renamed because of new 
technologies. 

For each activity relating to a target identity a CID is generated by the relevant network element. The CID consists of 
the following two identifiers: 

• Network IDentifier (NID); 

• Communication Identity Number (CIN) - optional. 

NOTE 2: For all non CC related records like SMS, SCI, etc. no correlation to a CC could be made. 

The CID distinguishes between the different activities of the target identity. It is also used for correlation between IRI 
records and CC connections. It is used at the interface ports HI2 and HI3. 

The Communication IDentifier is specified in the clauses below. For ASN.l coding details, see annex D. 

6.2.1 Network IDentifier (NID) 

The Network IDentifier (NID) is a mandatory parameter; it should be internationally unique. It consists of one or both 
of the following two identifiers: 

1) NWO/AP/SvP- identifier (mandatory): 

Unique identification of network operator, access provider or service provider. 

2) Network Element IDentifier (NEID) (optional): 

The purpose of the network element identifier is to uniquely identify the relevant network element carrying out 
the LI operations, such as LI activation, IRI record sending, etc. 

A network element identifier may be: 

an E.164 international node number in the case of circuit switched networks, such as ISDN, PSTN, 
GSM; 

an X.25 address; 

an IP address. 
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6.2.2 Communication Identity Number (CIN) - optional 

NOTE 1: Was called "Call Identity Number" in VI. 1.1 of ES 201 671 (see bibliography). It is renamed because of 
new technologies. 

This parameter is mandatory for IRI in case of reporting events for connection-oriented types of communication 
(e.g. circuit switched calls). 

The Communication Identity Number (CIN) identifies uniquely an intercepted communication session within the 
relevant network element. All the results of interception within a single communications session must have the same 
CIN. If a single interception subject has two or more communications sessions through the same operator, and through 
the same network element then the CIN for each session shall be different. 

NOTE 2: If two or more target identities, related either to an unique interception subject or to different interception 
subjects, are involved in the same communication the same CIN value may be assigned by the relevant 
network element to the communication sessions of the different target identities. 



7 HI1 : Interface port for administrative information 

The interface HIl is typically bi-directional. It is used to hand over the requests for lawful interception to the 
NWO/AP/SvP, such as orders for activation, deactivation and modification, and the corresponding notifications, and 
send other information to the LEA. 

There shall be no direct control over the NWO/AP/SvP's equipment by the LEA/LEMF. 

7.1 Information for the activation of lawful interception 

The HIl interface may be realized as manual or electronic processing, see clause 5.1. 

If the LEA requests lawful interception, the NWO/AP/SvP needs a minimum set of information to activate lawful 
interception in the network. 

The LEA shall provide the following information, for activation of LI: 

1) Identification of the interception subject: target identity. 

2) The agreed Lawful Interception IDentifier (LIID). 

3) Start and end (or duration) of the interception. 

4) Further specification of type of interception, i.e. kind of information to be provided (IRI or both IRI and CC). 

5) HI2 destination address of the LEMF, to which the IRI-Records shall be sent (if applicable). 

6) HI3 destination address of the LEMF, to which the Content of Communication (CC) shall be sent 
(if apphcable). 

7) Other network dependent parameters (e.g. location information, delivery mechanisms used for HI2 and HI3). 

8) A reference for authorization of the interception. 

9) Technical contact for issues relating to set-up and execution of the interception (e.g. solution of problems with 
communication links to the LEMF). 

10) Other information as required. 
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7.2 LI notifications towards the LEIVIF 

LI management notifications to the LEMF shall be sent in the following cases: 

1) After the activation of lawful interception. 

2) After the deactivation of lawful interception. 

3) After modification of an active lawful interception. 

4) In case of certain exceptional situations. 

For the definition of the information content of these LI management notifications, see clause D.4. 

8 HI2: Interface port for Intercept Related Information 

The HI2 interface port shall be used to transport all Intercept Related Information (IRI), i.e. the information or data 
associated with the communication services of the target identity apparent to the network. It includes signalling 
information used to establish the telecommunication service and to control its progress, timestamps, and, if available, 
further information such as supplementary service information or location information. Only information which is part 
of standard network signalling procedures shall be used within communication related IRI, see also clause 5.2; e.g. if 
information of the other party is not available, it need not be requested from the origin, by extra procedures, especially 
when such procedures are not provided by the used network protocols. 

Sending of the Intercept Related Information (IRI) to the LEMF shall in general take place as soon as possible, after the 
relevant information is available. 

In exceptional cases (e.g. data link failure), the Intercept Related Information (IRI) may be buffered for later 
transmission for a specified period of time. 

Within this clause only definitions are made which apply in general for all network technologies. Additional technology 
specific HI2 definitions are specified in related annexes (e.g. for circuit switched communication technologies, 
see clause A.3). 



8.1 Data transmission protocols 



The protocol used by the "LI application" for the encoding and the sending of data between the MF and the LEMF is 
based on already standardized data transmission protocols like ROSE or FTP, see annex C. 

The specified data communication methods provide a general means of data communication between the LEA and the 
NWO/AP/SvP's mediation function. They are used for the delivery of: 

• HIl type of information (notifications and alarms); 

• HI2 type of information (IRI records); 

• HI3 data type of information in certain circumstances (UUS, SMS, etc.). 

The present document specifies the use of the two possible methods for delivery: ROSE or FTP on the application layer 
and the BER on the presentation layer. The lower layers for data communication may be chosen in agreement with the 
NWO/AP/SvP and the LEA. 

The delivery to the LEMF should use the Internet protocol stack. 
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8.1 .1 Application for IRI (HI2 information) 



As defined in clause 5.2, the Handover Interface port 2 shall transport the Intercept Related Information (IRI) from the 
NWO/AP/SvP's MF to the LEMF. 

The individual IRI parameters shall be coded using ASN.l and the Basic Encoding Rules (BER). Where possible, the 
format of the information content shall be taken over from existing telecommunication standards, which are used for 
these parameters with the network already (e.g. the ISDN user part, DSSl, MAP and IP). Within the ASN.l coding for 
IRI, such standard parameters are typically defined as octet strings. 



8.2 Types of IRI records 



Intercept related information shall be conveyed to the LEMF in messages, or IRI data records, respectively. 
Four types of IRI records are defined: 

1) IRI-BEGIN record at the first event of a communication attempt, opening the IRI transaction; 

2) IRI-END record at the end of a communication or communication attempt, closing the IRI transaction; 

3) IRI-CONTINUE record at any time during a communication or communication attempt within the IRI 
transaction; 

4) IRI-REPORT record used in general for non-communication related events. 

For information related to an existing communication case, the record types 1 to 3 shall be used. They form an IRI 
transaction for each communication case or communication attempt, which corresponds directly to the communication 
phase (set-up, active or release). 

Record type 4 is used for non-communication related subscriber action, like Subscriber Controlled Input (SCI) for 
service activation. For simple cases, it can also be applicable for reporting unsuccessful communication attempts. 

The record type is an explicit part of the record. The 4 record types are defined independently of target communication 
events. The actual indication of one or several communication events, which caused the generation of an IRI record, is 
part of further parameters within the record's information content. Consequently, the record types of the IRI transactions 
are not related to specific messages of the signalling protocols of a communication case, and are therefore independent 
of future enhancements of the intercepted services, of network specific features, etc. Any transport level information 
(i.e. higher-level services) on the target communication-state or other target communication related information is 
contained within the information content of the IRI records. 



9 HIS: Interface port for Content of Communication 

The port HI3 shall transport the Content of the Communication (CC) of the intercepted telecommunication service to 
the LEMF. The Content of Communication (CC) shall be presented as a transparent en-clair copy of the information 
flow during an established, frequently bi-directional, communication of the interception subject. 

As the appropriate form of HI3 depends upon the service being intercepted, HI3 is described in relevant annexes. 

The HI2 and HI3 are logically different interfaces, even though in some installations the HI2 and HI3 packet streams 
might also be delivered via a common transmission path from a MF to a LEMF. It is possible to correlate HI2 and HI3 
packet streams by having common (referencing) data fields embedded in the IRI and the CC packet streams. This may 
be possible, e.g. for packet switched, but not for analogue circuit switched networks. 
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1 Performance and quality 
10.1 Timing 

As a general principle, within a telecommunication system, Intercept Related Information (IRI), if buffered, should be 
buffered for as short a time as possible. 

NOTE: If the transmission of Intercept Related Information fails, it may be buffered or lost. 



10.2 Quality 



The Quality of Service (QoS) associated with the result of interception should be (at least) equal to the 
Quality of Service (QoS) of the original Content of Communication (CC). 



1 1 Security aspects 



This clause will give an informative overview of the security properties and mechanisms that can be used to meet 
possible security requirements for the transportation of Lawful Intercepted data. 

11.1 Security properties 

A secure communication channel has the following properties: 

confidentiality; 

integrity; 

authentication; 

availability. 

Confidentiality means that it is impossible to interpret the data by eavesdropping on the communication link. 

Integrity means that any alteration or mutilation of the transported data is immediately detected. 

Authentication means that the communicating parties have verified and confirmed each others' identities. 

Availability means that the communicating parties have made agreements about up- and downtimes of the systems. In 
case of irregularities, alarm messages should be sent through another communication channel. Because of the nature of 
the transported data, confidentiality can be an issue. Lawful Intercepted data can also be confidential or secret by law 
and appropriate measures need to be taken to prevent eavesdropping by unauthorized third parties. 

Integrity can be an issue when Lawful Intercepted data is used as evidence in a criminal investigation. It must be 
provable that the data is unaltered and an exact representation of the intercepted communication. 

In the process of Lawful Interception (LI) it is very important to know that the LEMF is receiving the data from a real 
MF and the MP needs to be sure that it is sending its data to a real LEMF. If this verification of identity does not take 
place. Lawful Intercepted data might end up in the wrong place or the LEMF is processing data that is originating from 
an unauthorized source. 

The process of Lawful Interception (LI) takes place during well-defined periods of time. In case of any irregularities, 
appropriate actions need to be taken. Irregularities can be a sign of a breach of security, loss of data or detection of 
interception. 
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1 1 .2 Security mechanisms 



This clause will give an overview of possible mechanisms to achieve the properties as described above. Technical 
details are to be decided during the process of implementation. 

Confidentiality can be achieved by using encryption. A common technique is to use a symmetric encryption algorithm. 
A symmetric algorithm is an algorithm where both communicating parties use the same key for encryption and 
decryption. This key must be exchanged in a secure way. 

Integrity can be achieved using hashing algorithms. These algorithms generate a unique fingerprint of the transported 
data. When the transported data is altered, the fingerprint does not match anymore and appropriate actions can be 
undertaken (like retransmission of data). 

Authentication can be achieved using cryptographic techniques. A common technique is to use asymmetric encryption. 
In this technique, both parties have two keys: A public key and a private key. Data encrypted with one key can only be 
deciphered with the other. If party X encrypts something using the public key of party Y then party Y is the only one 
able to decrypt this data using his private key. If party X encrypts something using his private key then this data can 
only be deciphered using his public key. By combining these properties, both parties can make sure that they are 
communicating with the right party. 



1 2 Quantitative aspects 



See ES 201 158 [2]. The number of targets based on a percentage of subscribers should be provided at a national level 
together with an indication as to the expected usage. 
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Annex A (normative): 

Circuit switched network handover 

This annex is applicable to 64 kbit/s based circuit switched networks. 



A.1 Specific identifiers for LI 

In this clause, additional identifiers, which are needed in circuit switched networks are described here. See clause 6. 
A communication is a call in a circuit switched network. 



A.1 .1 CC Link IDentifier (CCLID) 



This identifier is only used at the interface ports HI2 and HI3 in case of the reuse of CC links (option B, 

see clause A.5.4.2). 

For each CC link, which is set up by the mediation function towards the LEMF, a CC Link IDentifier (CCLID) is 
transmitted in the HI2 records and HI3 set-up message in addition to CIN and NID. For the correct correlation of 
multiparty calls this identity number indicates in the IRI records of each multiparty call, which CC link is used for the 
transmission of the CC. 

The CCLID may use the same format as the CIN; in this case, it need not be transmitted explicitly during set up of the 
CC links, as part of HI3. The CIN may also implicitly represent the CCLID. 

A.1 .2 Circuit switched LI correlation between CC and IRI 

To assure correlation between the independently transmitted Content of Communication (CC) and Intercept Related 
Information (IRI) of an intercepted call the following parameters are used: 

• Lawful Interception IDentifier (LIID), see clause 6.1; 

• Communication IDentifier (CID), see clause 6.2; 

• CC Link IDentifier (CCLID), see clause A. L L 
These parameters are transferred from the MF to the LEMF in: 

• HI2, see clause A.3.2.1; 

• HI3, see clause A.4.2. 



A.1 .3 Usage of Identifiers 



The identifiers are exchanged between the mediation function and the LEMF via the interfaces HIl, HI2 and HI3. There 
exist several interface options for the exchange of information. Tables A. LI and A. L2 define the usage of numbers and 
identifiers depending on these options. 

NOTE: X in tables A. L 1 and A. L2: Identifier used within parameters of the interface. 
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Table A.1.1 : Usage of identifiers, IRI and CC transmitted; options A, B (see clause A.5.4) 



Identifier 


IRI and CC transmitted 


option A) 


IRI and CC transmitted (option B) 




HI1 


HI2 


HI3 


HI1 


HI2 


HI3 


LIID 


X 


X 


X 


X 


X 


X 


NID 




X 


X 




X 


X 


CIN 




X 


X 




X 


X (see note 1) 


CCLID 










X 


X (see note 2) 


NOTE 1 : The CIN of the first call for which this CC link has been set-up. 
NOTE 2: The CCLID may be omitted, see clause A.1 .1 . 



Table A.I. 2: Usage of identifiers, only IRI transmitted 



Identifier 


Only IRI transmitted 




HI1 


HI2 


LIID 


X 


X 


NID 




X 


CIN 




X 


CCLID 







A.2 HI1 : interface port for administrative state 

There are no additions beyond clause 7. 



A.3 HI2: interface port for IRI 

A.3.1 Definition of Intercept Related Information (IRI) 

Intercept Related Information (IRI) will in principle be available in the following phases of a call (successful or not): 

1) At call initiation when the target identity becomes active, at which time call destination information may or 
may not be available (set up phase of a call, target may be the originating or terminating party, or be involved 
indirectly by a supplementary service). 

2) At the end of a call, when the target identity becomes inactive (release phase of call). 

3) At certain times between the above phases, when relevant information becomes available (active phase of 
call). 

In addition, information on non-call related actions of a target constitutes IRI and is sent via HI2, e.g. information on 
Subscriber Controlled Input (SCI). 

The Intercept Related Information (IRI) may be subdivided into the following categories: 

1) Control information for HI2 (e.g. correlation information). 

2) Basic call information, for standard calls between two parties. 

3) Information related to supplementary services, which have been invoked during a call. 

4) Information on non-call related target actions. 
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A.3.2 Structure of IRI records 

Each IRJ-record contains several parameters. In the clauses below, the usage of these parameters is explained in more 
detail. 

Mandatory parameters are indicated as HI2 control information. Optional parameters are provided depending on the 
availability at the MF. For the internal structure of the IRI records, the ASN. 1 description, with the application of the 
Basic Encoding Rules (BER) is used. This ASN.l specification is enclosed in annex D. 

A.3.2. 1 Control information for HI2 

The main purpose of this information is the unique identification of records related to a target identity, including their 
unique mapping to the links carrying the Content of Communication (CC). In general, parameters of this category are 
mandatory, i.e. they have to be provided in any record. 

The following items are identified (in brackets: ASN.l name and reference to the ASN.l definition or clause D.5): 

1) Record type {IRIContent, see clause D.5) 

IRI-BEGIN, IRI-CONTINUE, IRI-END, IRI-REPORT-record types. 

2) Version indication (iRIversion, see clause D.5) 

Identification of the particular version of the HI2 interface specification. 

3) Communication IDentifier {Communicationldentifier, see clauses 6.2 and D.5). 

4) Lawful Interception IDentifier {Lawfullnterceptionldentifier, see clauses 6.1 and D.5). 

5) Date and time (TimeStamp, see clause D.5) 
Date and time of record trigger condition. 

The parameter shall have the capability to indicate whether the time information is given as Local time without 
time zone, or as UTC. Normally, the NWO/AP/SvP shall define these options. 

6) CC Link IDentifier {CC-Link-Identifier, see clause A. 1.2 for definition and clause D.5 for ASN.l definition). 

Table A. 3.1 summarizes the items of HI2 control information. It is mandatory information, except the CID - it may be 
omitted for non-call related IRI records - and the CCLID. Their format and coding definition is LI specific, i.e. not 
based on other signalling standards. 

Table A.3.1 : Parameters for LI control information in IRI records (HI2 interface port) 



IRI parameters: LI control information 


IRI parameter name 


ASN.l name (used in annex D) 


Type of record 


IRIContent 


Version indication 


iRIversion 


Lawful Interception IDentifier (LIID) 


Lawfullnterceptionldentifier 


Communication IDentifier (CID): 

- Communication Identity Number (CIN); 

- Network IDentifier (NID). 


Communicationldentifier 


Date and time 


TimeStamp 


CC Link IDentifier (CCLID) (only used in case of 
option B) 


CC-Link-Identifier 



A.3.2. 2 Basic call information 

This clause defines parameters within IRI records for basic calls, i.e. calls, for which during their progress no 
supplementary services have been invoked. In general, the parameters are related to either the originating or terminating 
party of a call; consequently, ASN.l containers are defined for the originating/terminating types of parties, which allow 
including the relevant, party-related information. The structure of these containers and the representation of individual 
items are defined in clause D.5. 

NOTE: A third type of party information is defined for the forwarded-to-party (see clause A.3.2. 3 on calls with 
supplementary services being invoked). 
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The items below are to be included, when they become available for the first time during a call in progress. If the same 
item appears identically several times during a call, it needs only to be transmitted once, e.g. in an IRI-BEGIN record. 
The ASN.l name of the respective parameters, as defined in clause D.5, is indicated in brackets: 

1) Direction of call {intercepted-Call-Direct) 

Indication, whether the target identity is originating or terminating Party. 

2) Address of originating and terminating parties {CallingPartyNumber or CalledP arty Number) 

If e.g. in case of call originated by the target at transmission of the IRI-BEGIN record only a partial 
terminating address is available, it shall be transmitted, the complete address shall follow, when available. 

3) Basic Service, LLC (Services-Information) 

Parameters as received from signalling protocol (e.g. BC, HLC, TMR, LLC). 

4) Cause (ISUP-parameters or DSSl-parameters-codeset-0) 

Reason for release of intercepted call. Cause value as received from signalling protocol. It is transmitted with 
the ASN.l container of the party, which initiated the release; in case of a network-initiated release, it may be 
either one. 

5) Additional network parameters 

E.g. location information {Location). 

Parameters defined within tables A.3.2 and A.3.3 shall be used for existing services, in the given ETSI format. National 
extensions may be possible using the ASN. 1 parameter National-Parameters. 

A.3.2. 3 Information on Supplementary Services, related to a call in progress 

The general principle is to transmit service related information within IRI records, when the corresponding 
event/information, which needs to be conveyed to the LEMF, is received from the signalling protocol. Where possible, 
the coding of the related information shall use the same formats as defined by standard signalling protocols. 

The selection, which types of events or information elements are relevant for transmission to the LEAs is conforming to 
the requirements defined in TS 101 331 [1] and ES 201 158 [2]. 

A dedicated ASN. 1 parameter is defined for supplementary services related to forwarding or re-routing calls 
(forwarded-to-Party information), due to the major relevance of these kinds of services with respect to LI. For the 
various cases of forwarded calls, the information related to forwarding is included in the 
originatingParty/terminatingParty/forwarded-to-Party information: 

1) If a call to the target has been previously forwarded, available parameters relating to the redirecting party(ies) 
are encapsulated within the originatingPartylnformation parameter. 

2) If the call is forwarded at the target's access (conditional or unconditional forwarding towards the forwarded- 
to-party), the parameters which are related to the redirecting party (target) are encapsulated within the 
terminatingP arty Information parameter. 

3) All parameters related to the forwarded-to-party or beyond the forwarded-to-party are encapsulated within the 
forwarded-to-Party ASN. 1 coded parameter. In addition, this parameter includes the supplementary-Services- 
Information, containing the forwarded-to address, and the redirection information parameter, with the reason 
of the call forwarding, the number of redirection, etc.). 

For the detailed specification of supplementary services related procedures see clause A.5. 

Parameters defined within tables A.3.2 and A.3.3 shall be used for existing services, in the given ETSI format. National 
extensions may be possible using the ASN.l parameter National-Parameters. 

A.3.2. 4 Information on non-call related Supplementary Services 

The general principle is to transmit non-call related service information as received from the signalling protocol. 
A typical user action to be reported is Subscriber Controlled Input (SCI). 
For the detailed specification of the related procedures see clause A. 5. 
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A.3.3 Selection of parameters for IRI records 

Relevant information on a call is taken from the call handling process, using wherever possible the coding 
specifications of the standardized ISDN protocols, or other standard network protocols. The protocol-defined 
information content is copied transparently into the information elements of the IRI records. This principle enables to 
reuse of internationally agreed standardization results; it allows reuse of existing functions within the NWO/AP/SvP 
equipment and in the terminal area (LEMF). 

Consequently, the present document needs for a large number of IRI-relevant items only to refer to other, existing 
standards, instead of including separate definitions in its scope. By this principle, also consistency issues and 
dependencies on the ongoing enhancements of the various protocols are minimized. 

The relevant parameters are listed in tables A.3.2 and A.3.3. 

For other signalling systems, which are not included in table A.3.2, the parameters shall be interpreted on a functional 
level, for defining their applicability in an IRI record; e.g. in case of a local call between analogue users, the called 
party number may only exist in an internal format of the switching system. Within the IRI records, such parameters 
shall also use the standardized coding. Existing interworking specifications, like EN 300 097-1 [14] shall be used for 
the conversion to the standard format. If the signalling system provides less information than defined by the standards in 
table A.3.2, spare or default values may be used instead. 

This method avoids the need to analyse for all situations, especially in the area of supplementary services, each detail of 
the service procedures, with specification of which parameter shall be sent in which state or situation. Instead, only a 
reference to the applicable standards is made. As soon as a parameter defined in one of the parameter tables appears 
within the target call protocol, it shall be transmitted within an IRI record. 

In addition to parameters taken from the call handling process, further, lawful interception specific parameters are 
needed, like the control information for LI. 

Three types of origins for the specification of HI2 parameters in IRI records can be differentiated: 

1) Parameters for LI control information; they are specific for the LI HI2 interface, and are specified in the 
present document (see table A. 3.1). 

2) Parameters used to convey information to the LEMF, which is retrieved from the target's call or service 
signalling protocol information (see table A.3.2). Within the IRI a standardized protocol coding is used. 

The relevant protocol specifications are the ISDN user part, as a generic protocol, used by several types of 
networks, and dedicated network protocols, e.g. DSSl or GSM standards. For a common implementation in 
different countries and to guarantee the possibility of an interception measure across borders only parameters 
defined in ETSI standards shall be used. 

3) Parameters used to convey information from events relating to the target call, but with no equivalent 
parameters being available in protocol standards. Such parameters shall be specified in the present document 
(see table A.3.3). 

The LI control information is a mandatory part of each IRI record (exception: CID), the information defined in 

table A.3.3 is included in IRI records, if the according parameter or event is detected during processing a call or a target 

identity related action. 
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Table A.3.2: List of parameters from standard protocols, which may be contained in IRI records 



IRI parameters: target call information, based on standard protocols 


IRI parameter name 


Name of ASN.1 parameter 
(of annex D) 


Related 
standard 


Ref. 


Three party conference invoke/result 
components (see note 2) 


Partylnformation 
supplementary-Services-Information 


DSS1 


EN 300 188-1 [20] 


Add on conference invoke/result 
components (see note 2) 


Partylnformation 
supplementary-Services-lnformation 


DSS1 


EN 300 185-1 [19] 


Bearer capability 


Partylnformation 
services-Information 


DSS1 


EN 300 403-1 [6] 


Call diversion information 


Partylnformation 
supplementary-Services-lnformation 


ISUP/DSS1 


EN 300 356 [5], 
EN 300 207-1 [21] 


Call transfer number 


Partylnformation 
supplementary-Services-lnformation 


ISUP 


EN 300 356 [5] 


Called party number 


Partylnformation 
CalledPartyNumber 


ISUP/DSS1/MAP 


EN 300 356 [5], 
EN 300 403-1 [6], 
TS GSM 09.02 [32] 


Called party subaddress 


Partylnformation 
supplementary-Services-lnformation 


DSS1 


EN 300 061-1 [10] 


Calling party number 


Partylnformation 
CallingPartyNumber 


ISUP/DSS1 


EN 300 356 [5], 
EN 300 403-1 [6] 


Calling party subaddress 


Partylnformation 
supplementary-Services-Information 


DSS1 


EN 300 061-1 [10] 


Cause indicator 


Release-Reason-Of-lntercepted-Call 
CallContentLinkCharacteristics 


ISUP/DSS1 


EN 300 356 [5], 
EN 300 403-1 [6] 


Cell id 


Location 


MAP/ISUP 


TS GSM 09.02 [32], 
EN 300 356 [5] 


Closed user group interlock code 


Partylnformation 
supplementary-Services-lnformation 


ISUP 




Connected number 


Partylnformation 
supplementary-Services-Information 


ISUP/DSS1 


EN 300 356 [5], 
EN 300 097-1 [14] 


Connected subaddress 


Partylnformation 
supplementary-Services-lnformation 


DSS1 


EN 300 097-1 [14] 


Explicit Call Transfer 

invoke/result components (see note 2) 


Partylnformation 
supplementary-Services-lnformation 


DSS1 


EN 300 369-1 [25] 


Facility (see note 3) 


Partylnformation 
supplementary-Services-lnformation 


DSS1 


EN 300 196-1 [29] 


Generic notification indicator 


Partylnformation 
supplementary-Services-lnformation 


ISUP 


EN 300 356 [5] 


Generic number 


Partylnformation 
supplementary-Services-Information 


ISUP 


EN 300 356 [5] 


High layer compatibility 


Partylnformation 
services-Information 


DSS1 


EN 300 403-1 [6] 


IMEI 


Partylnformation 
imei 


MAP 


TS GSM 09.02 [32] 


IMS! 


Partylnformation 
imsi 


MAP 


TS GSM 09.02 [32] 


Keypad facility 


Partylnformation 
supplementary-Services-Information 


DSS1 


EN 300 196-1 [29] 


Location number 


Location 


ISUP/MAP 


EN 300 356 [5], 
TS GSM 09.02 [32] 


Low layer compatibility 


Partylnformation 
services-Information 


DSS1 


EN 300 403-1 [6] 


MCID response indicator 


Partylnformation 
services-Information 


ISUP 


EN 300 356 [5] 


MSISDN 


Partyldentity/mslSDN 


MAP 


TS GSM 09.02 [32] 


Original called number 


Partylnformation 
supplementary-Services-lnformation 


ISUP 


EN 300 356 [5] 


Redirecting number 


Partylnformation 
supplementary-Services-lnformation 


ISUP/DSS1 


EN 300 356 [5], 
EN 300 207-1 [21] 


Redirection information 


Partylnformation 
supplementary-Services-lnformation 


ISUP 


EN 300 356 [5] 


Redirection number 


Partylnformation 
supplementary-Services-information 


ISUP/DSS1 


EN 300 356 [5], 
EN 300 207-1 [21] 
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IRI parameters: target call information, based on standard protocols 


IRI parameter name 


Name of ASN.1 parameter 
(of annex D) 


Related 
standard 


Ref. 


Subaddress transfer 


Partylnformation 
supplementary-Services-lnformation 


DSS1 


EN 300 369-1 [25] 


Transmission Medium Requirement 
(TMR) 


Partylnformation 
services-Information 


ISUP 


EN 300 356 [5] 


NOTE 1 : Column "Related standard" indicates the ETSI standard, which specifies the format and coding of the 

parameter. 
NOTE 2: Refers to several ASN.1 encoded elements, which are in the DSS1 protocol embedded in a facility 

information element. 
NOTE 3: The facility IE is only included, if it contains one or more of the parameters, which are parts of this table. 



Table A.3.3: List of LI specific parameters, which may be contained in IRI 



IRI parameters: target call information, LI specific definition 


IRI parameter name 


ASN.1 name (used in annex D) 


Direction of call 


intercepted-Call-Direct 


Call event, e.g.: 

- answer indication 

- call waiting indication 
hold indication 

- retrieve indication 

- suspend indication 
resume indication 


simplelndication 


Ringing duration 


ringingDuration 


Conversation duration 


conversationDuration 


CC link information 


callContentLinklnformation 


Subscriber controlled input data 


dSS1-parameters-codeset-0, or sciData 


NOTE: Format and coding details (see annex D). 



The general principle is that, if parameters included in table A. 3.2 are available, they shall be included in an IRI record, 
and be sent to the LEMF. Parameters of table A.3.3, which are not part of standard protocols, shall be included, when 
the according event or parameter, which needs to be reported to the LEMF, is detected. 

Parameters of table A. 3. 1 are present in all IRI records, except the Communication Identifier: it may be missing in 
IRI-REPORT records; if no target call is related to it. 

The list can be adapted to the requirements and feature specifications of an NWO/AP/SvP, and the laws and regulations 
of a country. That is, tables A.3.2 and A.3.3 may be extended nationally, or by a NWO/AP/SvP. Further in the present 
document, such extensions are referred to as national extensions or national parameters. 

The IIF for IRI parameter generation may be seen as a kind of screening function, which watches the signalling 
information flow related to a target, and copies those information elements, which match with an element type in the 
screening lists, defined by tables A.3.2 and A.3.3. 

The NWO/AP/SvP is not required to filter information out of the IRI. 

An instance of the IIF for IRI generation needs in general not to store the information it has sent, or other information 
on a call, for the purpose to be aware of the status or context of a call. Each IRI parameter is independent from previous 
or future parameters. Exceptions from this general principle can exist, e.g. in order to avoid multiple transmission of the 
same information. In such a case identical parameters do not have to be repeated in succeeding records, unless their 
content or value has changed. 

As it is indicated in table A.3.2, for a given logical parameter different format types may be used, depending on the type 
of network, and the call configuration. If a parameter is specified in the ISDN user part, and also identically in other 
standards, only the ISDN user part is referenced. 
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A.3.4 Coding of parameters in IRI records 

The parameters shall be included in the IRI records in a structured way. The structure is defined using ASN.l, the 
individual parameters are in terms of the ASN.l notation octet strings, which are taken over from the applicable 
standards. The ASN.l detailed coding specification is described in annex D. 

In case of the delivery of the IRI records to a LEA, when network specific extensions are used, the network specific 
parameters are transmitted as defined by the sending network. 

A.3.5 Information content of the IRI record types 

In principle, no restriction is made on which parameters shall or may be present in which IRI record type, except for the 
mandatory parameters, which are needed in all records. However, the logical information flow of calls implies that 
certain parameters will normally not appear in specific records; e.g. a called party number parameter is not included in 
an IRI-END record, because it has already been transmitted earlier. 



A. 4 HIS: interface port for Content of Communication 

The port HI3 shall transport the Content of the Communication (CC) of the intercepted telecommunication service to 
the LEMF. The Content of Communication (CC) shall be presented as a transparent en-clair copy of the information 
flow during an established, frequently bi-directional, communication of the interception subject. It may contain voice or 
data. A target call has two directions of transmission associated with it, to the target, and from the target. Two 
communication channels to the LEMF are needed for transmission of the Content of Communication (stereo 
transmission). 

The network does not record or store the Content of Communication (CC). 

A.4.1 Delivery of Content of Communication (CC) 

The transmission media used to support the HI3 port shall be standard ISDN calls, based on 64 kbit/s circuit switched 
bearer connections. The CC links are set up on demand to the LEMF. The LEMF constitutes an ISDN DSSl user 
function, with an ISDN DSS 1 basic or primary rate access. It may be locally connected to the target switching node, or 
it may be located somewhere in the target network or in another network, with or without a transit network in between. 
For network signalling, the standard ISDN user part shall be used. No modifications of the existing ISDN protocols 
shall be required. Any information needed for LI, like to enable correlation with the IRI records of a call, can be 
inserted in the existing messages and parameters, without the need to extend the ETSI standard protocols for the LI 
application. 

For each LI activation, a fixed LEMF address is assigned; this address is, within the present document, not used for any 
identification purposes. Identification and correlation of the CC links is performed by separate, LI specific information, 
see clauses 6 and A.L 

The functions defined in the ISDN user part standard. Version 1 (ETSI ISUP VI) are required as a minimum within the 
target network and, if applicable, the destination and transit networks, especially for the support of: 

• Correlation of HI3 information to the other HI port's information, using the supplementary service 
User-to-User Signalling 1 implicit (UUSl). 

• Access verification of the delivery call (see clause A.4.5). 

The bearer capability used for the CC links is 64 kbit/s unrestricted digital information; this type guarantees that the 
information is passed transparently to the LEMF. No specific HLC parameter value is required. 

The CC communication channel is a one-way connection, from the NWO/AP/SvP's IIF to the LEMF, the opposite 
direction is not switched through in the switching node of the target. 
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The scenario for delivery of the Content of Communication (CC) is as follows: 

1) At call attempt initiation, for one 64 kbit/s bi-directional target call, two ISDN delivery calls are established 
from the MF to the LEMF. One call offers the Content of Communication (CC) towards the target identity 
(CC R^ call/channel), the other call offers the Content of Communication (CC) from the target identity (CC T^ 
call/channel). See figure A.4.1. 

2) During the establishment of each of these calls, appropriate checks are made (see clause A. 4. 5). 

3) The MF passes during call set up, within the signalling protocol elements of the CC link the LIID and the CID 
to the LEMF. The LEMF uses this information to identify the target identity and to correlate between the IRI 
and CC (see clause A.4.2). 

4) At the end of a call attempt, each delivery call associated with that call attempt shall be released by the MF. 
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Figure A.4.1 : Content of Communication transmission from MF to LEMF 

A.4.1 .1 Delivery of TETRA CC over circuit switclned Inandover networks 

The mechanisms described above apply with the additional constraint that TETRA encoded speech shall be further 
encoded in accordance with the mechanisms defined in TS 100 392-3-6 [73] to fit to a standard 64 kbit/s bearer. 

NOTE: TETRA Switching and Management Infrastructures will in most cases carry TETRA encoded speech to 
allow for transcoder free operation (tandem-free operation) and where transcoding is not provided the 
referenced specification describes a means to transport the TETRA encoded speech over 64 kbit/s TDM 
bearers. 

A.4.2 Delivery of packetized Content of Communication (CC) 
(general) 

The operation for transmission of UUS and SMS may use the same mechanisms as used for HI2, or a dedicated link 
may be used. The ROSE operations for the transmission of the Content of Communication (HI3 data interface) shall 
follow the same rules as the one defined for the HI2 interface in clause 8.1. 

A differentiation is made between: 

1) bearer related or bearer unrelated end user information; and 

2) packet data services. 

NOTE: Exceptionally, for the GSM SMS service, this information may be passed via HI2. HI2 may be used 
optionally to pass the UUS information to the LEMF. 
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The physical or logical links supporting the Handover Interface traffic should be dimensioned to handle the bandwidth 
of the expected CC. 

A.4.2.1 Delivery of TETRA CC over packet switched Inandover networks 

The mechanisms described above apply with the additional constraint that TETRA encoded speech shall be encoded in 
accordance with the mechanisms defined in TS 100 392-3-7 [74]. 

A.4.3 Control information for circuit switched Content of 
Communication (CC) 

The delivery calls shall use unmodified standard ISDN protocols (DSS 1 , ISDN user part). Table A.4. 1 summarizes 
specific settings of parameters for the CC links. The User-to-User service 1 parameter is used during call set up (within 
the ISUP Initial Address Message (EN 300 356 [5]) or DSSl Set Up Message (EN 300 403-1 [6]), respectively) to 
transmit Ll-specific control information. This information is carried transparently and delivered to the specific LEMF 
remote user. 

To identify the delivered information, including correlating the delivery calls with the IRI records, parameters 1 to 3 
and 5 shall be included in the call set up. Parameters 6 to 9 specify settings of further relevant information. Other 
parameters of the ISDN protocols shall correspond to normal basic calls. 

Table A.4.1 : Definition of I-II3 specific signalling information; UUS1 coding details (see clause D.8) 



No. 


Used information element of 
CC link signalling protocol 


Information 


Purpose 


1 


CLI-Parameterwith attribute 
"network provided" 


See clause A.4.5 


LEMF can check identity of origin of call 


2 


UUS1 -parameter 


Lawful Interception IDentifier (LIID); 
see clause 6 


Identifier, identifying target identity 


3 


UUS1 -parameter 


Communication IDentifier (CID), 
see clause 6 


Identifier, identifying specific call of target 
identity 


4 


UUS1 -parameter 


CC Link IDentifier (CCLID), if 
required; see clause A.1 


Identifier, used for correlation CC link-IRI 
records 


5 


UUS1 -parameter 


Direction indication 
(communication from/towards 
target/combined (mono)) 


Signal from (TJ/towards (RJ target 
identity or combined 


6 


UUS1 -parameter 


Bearer capability of target call 


Indication to the LEMF of the basic 
service in use by the target 


7 


Closed user group interlock 
code 


Closed user group interlock code 


Supplementary Service CUG Security 
measure at set up of the CC link 


8 


Basic Service (BS) 


Basic Service (BS) of CC link: 
64 kbit/s unrestricted 


Guarantee transparent transmission of 
CC copy from MF to LEMF 


9 


ISDN user part forward call 
indicators parameter 


ISDN user part preference 
indicator: "ISDN user part required 
all the way" 


Guarantee transparent 
transmission of UUS1 and other 
supplementary services information 


10 


ISDN user part optional forward 
call indicators parameter 


Connected line identity request 
parameter: requested 


Sending of the connected number by the 
destination network 



Parameters 2, 3 and 4 are also present in the IRI records, for correlation with the CC links. Parameter 5 indicates in case 
of separate transmission of each communication direction, which part is carried by a CC link. Parameter 6, the basic 
service of the target call, can be used by the LEMF for processing of the CC signal, e.g. to apply compression methods 
for speech signals, in order to save storage space. Parameter 7 contains the CUG of the LEA. It is optionally used at set 
up the CC link to the LEA. Parameter 8, the basic service of the CC link, is set to "64 kbit/s unrestricted": All 
information of the R^, T^ channels can be transmitted fully transparently to the LEA. The setting of the ISDN user part 
indicator guarantees, that the services supporting the LI CC link delivery are available for the complete CC link 
connection. 
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The MF uses en-bloc dialling, i.e. there exists only one message in forward direction to the LEA. 

NOTE: The LEMF should at reception of the set up message not use the alerting state, it should connect 

immediately, to minimize time delay until switching through the CC links. Not all networks will support 
such a transition. Exceptionally, it may be necessary to send an alerting message before the connected 

message. 

The maximum length of the user information parameter can be more than the minimum length of 35 octets (national 
option, see EN 300 356 [5]), i.e. the network transmitting the CC links shall support the standard maximum size of 
131 octets for the UUS 1 parameter. 

The User-to-User service 1 parameter cannot be discarded by the ETSI ISUP procedures: the only reason, which would 
allow the ISUP procedures to discard it would be, if the maximum length of the message carrying UUS 1 would be 
exceeded. With the specified amount of services used for the CC links, this cannot happen. 

The signalling messages of the two CC channels (stereo mode) carry the same parameter values, except for the direction 
indication. 

See clause D.8 for the ASN.l definition of the UUSl LI specific content of the UUSl parameter. 



A.4.4 Exception handling 



A.4.4.1 Failure of CC links 

If a CC link cannot be set up, a certain number of repeat attempts during a certain period of time shall be made. 

NOTE: Typical values are three tries during 10 s. 

In case of a delay or total failure to transmit the Content of Communication, the target call is handled fully independent 
of the CC link, the CC information gets lost. 

A.4.4. 2 Fault reporting 

For several events the target switching function sends messages to the NWO/AP/SvP administration centre. Some 
example events are given in table A.4.2. 

Alternatively, all or some of these events may be transmitted directly to the LEMF. In this case, they are part of the LI 
management notification type of information. 

Delivery to the NWO/AP/SvP administration centre is not part of the HI. 

Table A.4.2: Typical events causing messages 



Event type 


Event causing message with LI alarm information 


CC link failure 


No answer from LEA 




LEA is busy 




CC link failed due to a COLP error 




CC link failed due to a CUG error 




CC link set up failure within the network 




CC link failed due to a lack of system resources 




General CC link set up failure 



A.4.5 Security requirements at the interface port HIS 

The process of access verification and additional (optional) authentication between the MF and the LEMF shall not 
delay the set up of the CC. 

For the protection and access verification of the Content of Communication (CC) delivery call the ISDN supplementary 
services CLIP, COLP and CUG shall be used when available in the network involved. 
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Generally any authentication shall be processed before the set-up of the CC links between the MF and the LEMF is 
completed. If this is technically not feasible the authentication may be processed after completion of the CC connection 
in parallel to the existing connection. 

A.4.5.1 LI access verification 

The supplementary service CLIP shall be used to check for the correct origin of the delivery call. 

NOTE: When using CLIP, the supplementary service CLIR is not applicable. 

The supplementary service COLP shall be used to ensure that only the intended terminal on the LEA's side accepts 
incoming calls from the Handover Interface (HI). 

To ensure access verification the following two checks shall be performed: 

• check of Calling Line Identification Presentation (CLIP) at the LEMF; and 

• check of connected Line identification Presentation (COLP) at the Handover Interface (HI) (due to the fact 
that the connected number will not always be transported by the networks involved, there shall be the 
possibility for deactivating the COLP check for a given interception measure. In addition, the COLP check 
shall accept two different numbers as correct numbers, i.e. the user provided number and the network provided 
number. Usually, the user provided number contains a DDI extension). 

A.4.5.2 Access protection 

In order to prevent faulty connections to the LEA, the CC links may be set up as CUG calls. 
In this case, the following settings of the CUG parameters should be used: 

• Incoming access: not allowed; 

• Outgoing access: not allowed; 

• Incoming calls barred within a CUG: no; 

• Outgoing calls barred within a CUG: yes. 

A.4.5.3 Autinentication 

In addition to the minimum access verification mechanisms described above, optional authentication mechanisms 
according to the standard series ISO 9798: "Information technology - Entity authentication" parts 1 to 5 may be used 
(see bibliography). 

These mechanisms shall only be used in addition to the access verification and protection mechanisms. 

A.5 LI procedures for circuit switched supplementary 
services 

A.5.1 General 

In general, LI shall be possible for all connections and activities in which the target is involved. The target shall not be 
able to distinguish alterations in the offered service. It shall also not be possible to prevent interception by invoking 
supplementary services. Consequently, from a supplementary services viewpoint, the status of interactions with LI is 
"no impact", i.e. the behaviour of supplementary services shall not be influenced by interception. 

Depending on the type of supplementary service, additional CC links to the LEA may be required, in addition to already 
existing CC links. 

Within the IRI records, the transmission of additional, supplementary service specific data may be required. 
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Supplementary services, which have an impact on LI, with respect to CC links or IRI record content, are shown in 
table A.5.1. The table is based on ISDN services (DSSl protocol specifications), it considers the services which have 
been standardized at the time of finalizing the present document. Future services should be treated following the same 
principles. 

NOTE 1 : Co-ordination of handling of new services should be performed via ETSI/TC LI. If required, additions 
will be included in a subsequent version of the present document. 

Services defined for other signalling protocols, which can be related to the services in the table shall be treated in the 
same manner (see also below). Other protocols are e.g.: 

• Analogue user signalling; in general, no ETSI standards are available for supplementary services. 

• Mobile user protocols of the GSM, defined within the MAP (TS GSM 09.02 [32]). 

The question of Lawful Interception (LI) with Intelligent Networks is not covered in the present document (see note 2). 

NOTE 2: The general principle is, that LI takes place on the basis of a technical identity, i.e. a directory number. 

Only numbers which are known to the NWO/AP/SvP, and for which LI has been activated in the standard 
way, can be intercepted. No standardized functions are available yet which would enable an SCF to 
request from the SSF the invocation of LI for a call. 

Additional CC links are only required, if the target is the served user. IRI Records may also carry data from other 
parties being served users. 

Clause A.6 specifies details for relevant services: 

• The procedures for CC links, depending on the call scenario of the target. 

• Related to the IRI records, the point in time of sending and supplementary service specific information. 

• Additional remarks for services with "no impact" on LI. 

The specifications for supplementary services interactions are kept as far as possible independent of the details of the 
used signalling protocols; service related events are therefore described in more general terms, rather than using 
protocol dependent messages or parameters. 

Interactions with services of the same family, like call diversion services, are commonly specified, if the individual 
services behaviour is identical, with respect to LI. 

With respect to the IRI records, clause A.6 specifies typical cases; the general rules for data which shall be included in 
IRI records are defined in clause 8, specifically in clauses A.3.3 and A.5.3. 

Services, which are not part of table A.5 . 1 , do not require the generation of LI information: no CC links are generated or 
modified, and no specific information on the service is present in the IRI records. That is, these services have 
"no impact" on LI; no special functions for LI are required. However, within the IIF, functions may be required to 
realize the principle, that the service behaviour shall not be influenced by LI. 

"No impact" is not automatically applicable for new services. Each new service has to be checked for its impact on LI. 
Additionally, also services using other than the DSSl protocols, which cannot be related to one of the DSSl based 
services, may have impact on LI. 

The present document does not intend to give a complete description of all possible cases and access types of 
interactions with supplementary services. 
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Table A.5.1 : Supplementary Services with impact on LI CC links or IRI records content; 

see also clause A.6 



Supplementary 
Service 


Abbr. 


CC links: additional calls, impact 


IRI items related to service 


Call Waiting 


CW 


CC links for active or all calls (option A/B) 


Target: call waiting indication, calling party 

address 

other party: generic notification indicator 


call HOLD 


HOLD 


CC links for active or all calls (option A/B) 


Target: call hold indication 

other party: generic notification indicator 


call RETRIEVE 


RETRIEVE 


CC links for active or all calls (option A/B) 


Target: call retrieve indication 

other party: generic notification indicator 


Explicit Call 
Transfer 


ECT 


Before transfer: see HOLD 

After transfer: LI may or may not be stopped 


Target: components of Facility IE 
other party: generic notification indicator 


Terminal 
Portability 


TP 


No impact on CC links 


Target: call suspend/resume indications 
other party: generic notification indicator 


SUBaddressing 


SUB 


No impact on CC links 


Subaddress IE, as available 
(calling, called, etc.) 


Calling Line 

Identification 

Presentation 


CLIP 


No impact on CC links 


CLI parameter: part of originating-Party 
information 


Calling Line 

Identification 

Restriction 


CLIR 


No impact on CC links 


Restriction indicator is part of CLI parameter 


connected Line 

identification 

Presentation 


COLP 


No impact on CC links 


COL parameter: part of terminating-Party 
information 


connected Line 

identification 

Restriction 


COLR 


No impact on CC links 


Restriction indicator is part of COL parameter 


Closed User 
Group 


CUG 


No impact on CC links 


CUG interlock code 


add on 
CONFerence 


CONF 


Tj^: signal from target; R^ call sum signal 
CC links depending on option A/B 


Target: components of Facility IE 
other party: generic notification indicator 


Three PartY 
conference 


3PTY 


Initially: held and active calls see HOLD 
Conf.: see CONF 


Target: components of Facility IE 
other party: generic notification indicator 


Call Forwarding 
Unconditional; 
(see note) 


CFU 


One CC link for each call, which is 
forwarded by the target 
Forwarding by other parties: 
no impact 


Target: see clause A.3.2.3, point 2, 3; if 
redirecting no. = target DN: not included 
Other party (call to target is a forwarded call): 
See clause A.3.2.3, point 1 
Other party (call from target gets forwarded): 
See clause A.3.2.3, point 3 


Call Forwarding 
No Reply; 
(see note) 


CFNR 


1) basic call with standards CC links, 
released after time-out (incl. CC links) 

2) forwarding: same as CFU 


1 ) basic call, released after time-out, 
standard IRI 

2) forwarding: same parameters as for CFU 


Call Forwarding 
Busy; (see note) 


CFB 


Network determined user busy: see CFU 
User determined user busy: see CFNR 


Network determined user busy: see CFU 
user determined user busy: see CFNR 


Call Deflection 


CD 


See CFNR 


See CFNR 


Partial Rerouting 


PR 


See CFNR 


See CFNR 


IVIalicious Call 
IDentification 


MCID 


No impact on CC links 


IVICID response indicator sent at invocation 


User-to-User 
Signalling 1,2,3 


UUS 


No impact on CC links 


User-to-user information, more data IE 
(part of HI2 information, see clause D.5, 
part of HI3 information, see clause D.6) 


FallBack 
procedure (not a 
Supplementary 
Service) 


FB 


No impact on CC links 


Target or other party: new basic service IE 


NOTE: Other variants of Call Forwarding (CF), like forwarding to fixed numbers, to information services, etc. are 
assumed to be covered by the listed services. 
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A.5.2 CC link Impact 

The column "CC links: additional calls, impact" (see table A. 5.1) defines, whether: 

• for the related service CC links shall be set up, in addition to the CC links for a basic call; 

• already existing calls are impacted, for example by disconnecting their information flow. 

The CC link impact relates always to actions of a target being the served user. Services invoked by other parties have no 
CC link impact. 

A. 5. 3 IRI impact, general principle for sending IRI records 

The column "IRI items related to service" (see table A. 5.1) specifies, which parameters may be transmitted to the LEA 
within the IRI records. For several services, it is differentiated, whether the target or the other party is the served user. 

The table specifies, which parameters are applicable in principle. That is, these parameters are normally sent to the 
LEA, immediately when they are available from the protocol procedures of the service. In many cases, additional 
IRI-CONTINUE records, compared to a basic call, will be generated. However, not each service related signalling 
event needs to be sent immediately within an individual record. Exceptions may exist, where several events are included 
in one record, even if this would result in some delay of reporting an event (this may be implementation dependent). 
Each record shall contain all information, which is required by the LEA to enable the interpretation of an action. 

EXAMPLE: The indication of call forwarding by the target shall include the forwarded-to number and the 
indication of the type of forwarding within the same record. 

The complete set of parameters, which are applicable for IRI, is specified in clause A. 3. 3 (see tables A. 3. 2 and A. 3. 3). 

If during procedures involving supplementary services protocol parameters, which are listed in tables A. 3. 2 and A.3.3 
become available, they shall be included in IRI Records. This rule is directly applicable for parameters received via 
ISUP and DSSl signalling protocols. Regarding all other protocols, e.g. of analogue users, the mapping to the ISDN 
protocols, as defined in clause A.3.3 is assumed, before discriminating, which (mapped) parameters are copied to the 
IRI records. 

IRI data are not stored by the IIP or MP for the purpose of keeping information on call context or call configuration, 
including complex multiparty calls. The LEMP (electronically) or the LEA's agent (manually) shall always be able, to 
find out the relevant history on the call configuration, to the extent, which is given by the available signalling protocol 
based information, within the telecommunication network. 

Service invocations, which result in invoke and return result components (as defined in table A.3.2) need only be 
reported in case of successful invocations. One IRI record, containing the invoke component, possibly including 
additional parameters from the return result component, is sufficient. Instead of the DSSl functional protocol 
components, for specific networks other ETSI-standardized components may be used, e.g. of the MAP 
(TS GSM 09.02 [32]). 

With respect to the inclusion of LI specific parameters, see also the parameter specifications and example scenarios in 
clause E.3 for more details. 

Details of e.g. the definition of the used record type, their content, the exact points in time of sending, etc. follow from 
the according service specifications; in some cases, they are specified explicitly in clauses A. 6 and E.3. 

A. 5. 4 Multi party calls - general principles, options A, B 

Each network must adopt option A or B according to local circumstances. 

With respect to IRI, each call or call leg owns a separate IRI transaction sequence, independent of whether it is actually 
active or not. 

With respect to the CC links, two options (A, B) exist, which depend on laws and regulations, see below. Active call or 
call leg means in this context, that the target is actually in communication with the other party of that call or call leg; 
this definition differs from the definition in EN 300 403-1 [6]. 
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A.5.4.1 CC links for active and non-active calls (option A) 

For each call, active or not, separate CC links shall be provided. This guarantees, that: 

• changes in the call configuration of the target are reflected immediately, with no delay, at the LEMF; 

• the signal from held parties can still be intercepted. 

It is a network option, whether the communication direction of a non-active call, which still carries a signal from the 
other party, is switched through to the LEMF, or switched off. 



Target 



on hold 



IIF 



WIF 



Other parties 
=t PI on hold 
=^ P2 on hold 
=^ P3 active 



LEMF 



Figure A.5.1 : CC link option A (example for call hold supplementary service) 

A.5.4.2 Reuse of CC links for active calls (option B) 

CC links are only used for calls active in their communication phase. Changes in the call configuration may not be 
reflected at the LEMF immediately, because switching in the IIF/MF is required, and the signal from the held party is 
not available. 

Each time, another target call leg uses an existing CC link, an IRI-CONTINUE record with the correct CID and CCLID 
shall be sent. 

NOTE: Even when option B is used, more than one CC link may be required simultaneously. 



Target 



on hold 



MF 



LEMF 



other parties 
=*: PI on hold 
=t P2 on hold 
^ P3 active 



Figure A.5.2: CC link option B (example for call hold supplementary service) 
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A.5.5 Subscriber Controlled Input (SCI): 

Activation/Deactivation/lnterrogation of services 

For user procedures for control of Supplementary Services (Activation/Deactivation/Interrogation), a special IRI record 
type (IRI-REPORT record) is defined to transmit the required information. 

If the DSSl Functional Protocol (EN 300 196-1 [29]) is used by the target, the functional information elements, usually 
ASN.l encoded, are copied to the IRI-REPORT record as received by the target exchange. In case of analogue targets 
or use of the ISDN keypad protocol (EN 300 122-1 [39]) (digits or IA5-characters), other appropriate parameters 
identifying the services are used. They may consist of the string sent by the user, or system-specific parameters, which 
identify the service sufficiently. 

The IRI-REPORT record shall contain an indicator, whether the request of the target has been processed successfully or 
not. 

At the exchange, where the subscriber data of a target shall be modified via a remote control procedure, an 
IRI-REPORT record shall be generated as if the control procedure had taken place locally. 



A.6 Detailed procedures for circuit switched 
supplementary services 

A.6.1 Advice of Charge services (AOC) 

No impact. 

Advice of Charge information is not included in IRI records. 

A.6.2 Call Waiting (CW) 

A.6.2.1 Call Waiting (CW) at target: CC links 

In case of option A "CC links for all calls", a CC link is set up for the waiting call, using the standard procedures for 
terminating calls. In case of option B "CC links for active calls", no CC link is set up for the waiting call, it is treated 
like a held call. 

With respect to CC links, the same configurations as for Call Hold apply. 

Procedure, when the target accepts the waiting call: see retrieve of a held call (see clause A.6. 3). 

A.6.2.2 Call Waiting: IRI records 
A. 6. 2.2.1 Target is served user 

If Call Waiting is invoked at the target access by another (calling) party: the IRI-BEGIN record or a following 
IRI-CONTINUE record for the waiting call shall contain the LI specific parameter call waiting indication. 

A.6. 2.2. 2 Other party is served user 

If Call Waiting is invoked at the other (called) party's access: if a CW notification is received by the target's switching 
node, it shall be included in an IRI-CONTINUE record; it may be a separate record, or the next record of the basic call 
sequence. 
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A.6.3 Call Hold/Retrieve 

A.6.3.1 CC links for active and non-active calls (option A) 

If an active call is put on hold, its CC links shall stay intact; as an option, the signal from the held party is not switched 
through to the LEMF. 

If the target sets up a new call, while one call is on hold, this call is treated like a normal originating call, i.e. a new LI 
configuration (CC links, IRI records) is established. 

A.6.3. 2 Reuse of CC links for active calls (option B) 

If an active call is put on hold, its CC links shall not immediately be disconnected; as an option, the signal from the held 
party is not switched through to the LEMF. 

If the target sets up a new call, or retrieves a previously held call, while one target call, which still owns CC links, is on 
hold, these CC links shall be used for the signals of the new active call. 

A.6.3.3 IRI records 

A.6.3. 3.1 Invocation of Call Hold or Retrieve by target 

An IRI-CONTINUE record with the LI specific parameter hold indication or retrieve indication, respectively, shall be 
sent. 

A.6.3. 3. 2 Invocation of Hold or Retrieve by other parties 

An IRI-CONTINUE record with a call hold or retrieve notification shall be sent if it has been received by the signalling 
protocol entity of the target call. 

A.6.4 Explicit Call Transfer (ECT) 
A.6.4.1 Explicit Call Transfer (ECT), CC link 

During the preparation phase of a transfer, the procedures for Call Hold/Retrieve are applicable. 

If the served (transferring) user is the target, its original call is released. This terminates also the CC link, and causes an 
IRI-END record to be sent. 

After transfer, two options exist: 

1) For the transferred call, CC links (and IRI records) shall be generated, in principle like for a forwarded call 
(similar to procedures in clause A.6.16.1, case b). 

2) The transferred call shall not be intercepted. 

A.6.4.2 Explicit Call Transfer (ECT), IRI records 

In addition to the basic or hold/retrieve/waiting call related records and parameters, during the reconfiguration of the 
call, ECT-specific information at the target's access is sent to the LEMF within IRI-CONTINUE records. 

When the target leaves the call after transfer, an IRI-END record is sent, and the LI transaction is terminated. Options 
for the new call, after transfer: see clause A.6.4. L 
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A.6.5 Calling Line Identification Presentation (CLIP) (IRI Records) 
A.6.5.1 Call originated by target (other party is served user) 

The standard CLI parameter of an originating target is included as a supplementary service parameter in the IRI records. 

If for the access (BRI or PRI) of the target a special arrangement according to EN 300 089 [54] exists, whereby the user 
provides a user provided, not screened number, this number is included in the IRI-BEGIN record (originating-Party 
information), as a generic number parameter. The network provided default number of the access is, as without this 
arrangement, also included in the IRI record. 

A.6.5. 2 Call terminated at target (target is served user) 

The CLI sent from the other party is included in the IRI-BEGIN record (originating-Party information), irrespective of 
a restriction indication. An eventually received second number (case two number delivery option) is included in the IRI 
record as supplementary services information (Generic Number parameter). 

A.6.6 Calling Line Identification Restriction (CLIR) 

For use by LI, the restriction is ignored, but copied within the CLI parameter to the IRI record. 

A. 6. 7 connected Line identification Presentation (COLP) 
A.6.7.1 Call terminated at target (other party is served user) 

A connected number parameter received from the target shall be included in an IRI record (terminating-Party 
information). In cases where a special arrangement applies, the user provided and the network provided default number 
of the access is included in the IRI record. 

A.6.7.2 Call originated by target (target is served user) 

If available, a connected number parameter as received from the other (terminating) party shall be included in an IRI 
record (terminating-Party information). Any additional number, e.g. a Generic Number, shall also be included in the IRI 
record. 

A. 6. 8 connected Line identification Restriction (COLR) 

For use by LI, the restriction is ignored, but copied within the COL parameter to the IRI record. 

A.6.9 Closed User Group (CUG) 

In case of a CUG call, the closed user group interlock code shall be included in an IRI. 

A.6.10 Completion of Call to Busy Subscriber (CCBS) 

No impact. 

The first call, which meets a (terminating) busy subscriber, and is released subsequently, is treated like a standard busy 
call, with no CCBS related IRI information. 

The procedures for CCBS, until starting a new call attempt from the served user to the terminating user, including the 
CCBS recall, are not subject of LI. 
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A.6.1 1 CONFerence call, add-on (CONF) 
A.6.1 1.1 CONFerence calls, add on: CC links 

The CC links carry the same bit stream as sent to/received from the target, that is, the R^ call contains the sum signal of 
the conference, and the T^^ call contains the signal from the target. 

The general rules for multi party calls (see clause A.5.4) apply also for the various possible states during a conference 
(isolate, split, etc.). The call to the conference device as such is treated like a standard call. In case of a n-party 
conference, there exist n + 1 CC links in case of option "CC link for all calls", or just one CC link, in case of option 
"CC link for active calls". 

A.6.1 1 .2 Conference calls: IRI records 

In addition to the basic or hold/retrieve/waiting call related records and parameters, during the set up and eventual 
reconfigurations of a conference, CONF-specific information is sent to the LEMF within IRI records. 

A.6.1 2 Three Party Service (Conference) 
A.6.1 2.1 CC links 

a) Target is conference controller: 

The 3PTY conference originates from a configuration with two single calls (one active, one held). When 
joining the calls to a conference, the CC links, which have carried the signals of the active target call are used 
to transmit the conference signals; that is, the R^^^ call contains the sum signal of the conference, the T^^^ call 

contains the signal from the target. 

The second CC link set, for the previously held call stays intact. If the conference is released, and the initial 
state (1 held, 1 active call) is re-established, the required CC links are still available. 

b) Target is passive party of conference: 
No impact on CC links. 

A.6.1 2.2 Three Party Service, IRI Records 

For the events indicating the start and the end of the 3PTY conference, IRI records are generated. 

A.6.13 Meet-Me Conference (MMC) 

No impact; calls to a MMC are treated as standard calls; the MMC device is not required to be subject of LI. 

A.6.14 Direct Dialling In (DDI) 

LI may be applied to a PABX access DN or to a DDI extension number according to national laws and requirements. 

A.6.1 5 Multiple Subscriber Number (IVISN) 

LI shall be activated individually per MSN. 

If LI has to be activated for a whole ISDN B A, activation commands shall be input by the LI administrator for each 
number; administrative procedure shall ensure, that all numbers are covered. If during a surveillance a MSN is added or 
removed, a LI administrative message shall be generated, see clause 7.2. 
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A.6.16 Diversion services (DIV) 

Calls to a target, with a called party number equal to the intercepted target DN(s), but forwarded, are intercepted, 
i.e. CC links are set up, and IRI records are sent to the LEA. This applies for all kinds of call forwarding. 

For calls forwarded by the other party (calling or called), the available diversion-related information is sent to the LEA. 

A.6.16.1 Call Diversion by target 

A.6. 1 6. 1 . 1 Call Diversion by target, CC links 

In order to handle call diversion services by applying, as far as possible, common procedures, the following two cases 
are differentiated: 

a) Call Forwarding Unconditional (CFU), Call Forwarding Busy (NDUB): 

In these cases, forwarding is determined, before seizing the target access. CC links are set up, immediately, for 
the forwarded call. 

Other variants of Call Forwarding (CF) with immediate forwarding, i.e. without first seizing the target access, 
are handled in the same way (e.g. unconditional Selective Call Forwarding). 

b) Call Forwarding No Reply, Call Forwarding Busy (UDUB), Call Deflection, Partial Rerouting: 
Initially, the target call is set up, and the call is intercepted like a basic call. 

When forwarding takes place (e.g. after expiry of the CFNR timer), the original call is released; this may cause 
also a release of the CC links. In such case two optional IRI record handling may apply: 

1) For the original call an IRI -END record is sent. For the forwarded call a new set up procedure, including 
new LI transaction may take place with new set of IRI records (starting with IRI-BEGIN record sent to 
the LEA). 

2) For the forwarded call the IRI-CONTINUE record is generated and sent to a LEA, indicating the CFNR 
invocation. 

Other variants of Call Forwarding (CF) with forwarding after first seizing the target access, are handled in the same 
way. 

In case of multiple forwarding, one call may be intercepted several times, if several parties are targets. Considering the 
maximum number of diversions for one call of 5 (ITU recommended limit), one call can be intercepted 7 times, from 
the same or different LEAs. In principle, these procedures are independent of each other. 

A.6.1 6.1 .2 Call Diversion by target, IRI records 

See clause A.3.2.3, case 2, related to the target's information, and case 3, related to the forwarded-to -party information. 
As above for the CC links, the diversion types a) and bl, 2) are differentiated: 

• for case a) and b2) diversions, the IRI is part of one transaction, IRI-BEGIN, -CONTINUE, -END; 

• for case bl) diversions, a first transaction informs about the call section, until diversion is invoked 
(corresponding to a basic, prematurely released call), a second transaction informs about the call section, when 
diversion is invoked (corresponding to case a)). 



A.6.1 6.2 Forwarded call terminated at target 



The CC link is handled in the standard way. The IRI-BEGIN record contains the available call diversion information, 
see clause A.3.2.3, case 1. 
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A.6.1 6.3 Call from target forwarded 



The CC link is handled in the standard way. The IRI-BEGIN and possibly IRI -CONTINUE records contain the 
available call diversion related information, see clause A. 3. 2. 3, case 3. 

A.6.1 7 Variants of call diversion services 

Variants of the above "standard" diversion services are treated in the same way as the corresponding "standard" 
diversion service. 

A.6.1 8 Void 

A.6.1 9 IVIalicious Call IDentification (IVICID) 

CC links: no impact. 

IRI records: If a terminating target or other party invokes MCID, the MCID response indicator parameter shall be 
included in a dedicated or the next regular IRI record. 

A.6.20 SUBaddressing (SUB) 

The different types of subaddress information elements are part of the IRI records, in all basic and supplementary 
services cases, where they are present. 

A.6.21 Terminal Portability (TP) 
A.6.21.1 CC links 

No impact. 

A.6.21 .2 IRI records 

A.6.21 .2.1 Invocation of Terminal Portability by target 

Sending of the LI parameters suspend indication or resume indication in an IRI-CONTINUE record. 

A.6.21 .2.2 Invocation of Terminal Portability by other parties 

Sending of the generic notification indicator, values user suspended or user resumed in an IRI-CONTINUE record. 

A.6.22 User-to-User Signalling (UUS) 

User-to-User parameters of services UUSl, UUS2 and UUS3 shall be reported as HI3, see clause A.4, or via HI2, 
see clause A.5. 

If User-User information is not delivered from a target to the other party (e.g. due to overload in the SS No. 7 network), 
no notification is sent to the LEA. 

A.6.23 Abbreviated Address (AA) 

No impact. The service access code and abbreviated number (user input) is not included in IRI records. 
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A.6.24 Fixed Destination Call (FDC) 

No impact. The service access code (if applicable) is not included in IRI records. 

A.6.25 Alarm Call (AC)/Wake-Up Service (WUS) 

No impact. A Wake-up call is intercepted in the standard way; the identity of the originating party may be missing. 

A.6.26 Incoming Call Barring (ICB) 

No impact. 

a) Case terminating call to a target with ICB active: 

In general, the barring condition of a target is detected before the target access is determined, consequently, an 

IRI-REPORT records is generated. 

If the access would be determined, a standard IRI-END record is generated, with the applicable cause value. 

b) Case target calls a party with ICB active: 

In general, an IRI-BEGIN record has been sent already, and CC links have been set up. Consequently, a 
standard IRI-END record is generated, with the applicable cause value. 

A.6.27 Outgoing Call Barring (OCB) 

No impact. 

For a barred call, a standard record may be generated; its type and content are depending on the point in the call, where 
the call was released due to OCB restrictions. 

A.6.28 Completion of Calls on No Reply (CCNR) 

No impact. See remarks to service CCBS. 

A. 6. 29 Reverse charging 

No impact. 

A.6.30 Line hunting 

All accesses of the group shall get the interception profile, independently of each other, if the whole group has to be 
intercepted (responsibility of the LI operator). 

A.6.31 Message Wait Indication (MWI) 

No impact. The information, that a message is waiting, is not sent to the LEA. 

A.6.32 Name display 

No impact. Name strings are not included in IRI records. 
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A. 6. 33 Tones, announcements 

No impact. 

If the normal procedures, depending on the call state, result in sending the tone or announcement signal on the R^ CC 
link channel, this shall be transmitted as CC. 



A.7 Void 



A.8 GSM circuit switched technology annex 
A.8.1 Functional architecture 

The following picture contains the reference configuration for the lawful interception (see 3GPP TS 03.33 [42]). 

There is one ADMinistration Function (ADMF) in the network. Together with the delivery functions it is used to hide 
from the MSC/VLR and GMSC that there might be multiple activations by different Law Enforcement Agencies 
(LEAs) on the same target. 
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Figure A.8.1 : Reference configuration for GSIV! circuit switchied 

The reference configuration is only a logical representation of the entities involved in lawful interception and does not 
mandate separate physical entities. This allows for higher levels of integration. 

A call could be intercepted based on several identities (MSISDN, IMSI, IMEI) of the same target. 

Interception based on IMEI could lead to a delay in start of interception at the beginning of a call and interception of 
non-call related events is not possible. 

For the delivery of the CC and IRI the MSC/VLR or GMSC provides correlation number and target identity to the DF2 
and DF3 which is used there in order to select the different LEAs where the product shall be delivered to. 



£75/ 



52 



ETSI TS 101 671 V3.1.1 (2007-06) 



A.8.2 Correlation of CC and IRI (see clause 6) 

Correlation of the present document IDs to 3GPP TS 03.33 [42] IDs. 

The ID Lawful Interception Identifier (LIID) out of the present document is supported at the IIF (GSM) with warrant 
reference number. 

Parameters out of the present document, see clause 6.2: 

Communication IDentifier (CID) 

For each call or other activity relating to a target identity a CID is generated by the relevant network element. The CID 
consists of the following two identifiers: 

Network IDentifier (NID); 

Communication Identity Number (CIN). 

Intercepting Node ID is used for the NID in the GSM system. 

The correlation number is used for the CIN. 

For the Communication IDentifier (CID) in the GSM system we use the combination of Interception Node ID and the 
correlation number. 



A.8.3 HIS (delivery of CC) 



CC will be delivered as described in clause A.4. 

Exceptionally, SMS will be delivered via HI2. 

Correlation information in HI3 will be delivered as described in clause D.8 and as an option annex E. 



A.8.4 HI2 (delivery of IRI) 



The events defined in 3GPP TS 03.33 [42] are used to generate records for the delivery via HI2. 

There are eight different events type received at DF2 level. According to each event, a record is sent to the LEMF if this 
is required. Table A.8.1 gives the mapping between event type received at DF2 level and record type sent to the LEMF. 

It is an implementation option if the redundant information will be sent for each further event. 

Table A.8.1 : Structure of the records for GSM (CS) 



Event 


IRI record type 


Call establishment 


BEGIN 


Answer 


CONTINUE 


Supplementary service 


CONTINUE 


Handover 


CONTINUE 


Release 


END 


Location update 


REPORT 


Subscriber controlled input 


REPORT 


SMS 


REPORT 



A set of information is used to generate the records. The records used transmit the information from mediation function 
to LEMF. This set of information can be extended in MSC/VLR or GMSC or DF2/MF, if this is necessary in a specific 
country. Table A.8.2 gives the mapping between information received per event and information sent in records. 
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IRI-related information, such as receiving MSISDN, which is included as header information in the SMS message body 
that is sent to the SMS service centre, is to be included in IRI records. 

NOTE: In some jurisdictions an authorization for interception of IRI only means that SMS message body is not 
included in what the LEA is allowed to receive. In such cases it is essential that the relevant party 
information is included in IRI records, even if such information for technical reasons is included in what 
the intercepting network element sees as "contents". 

Table A.8.2: Description of parameters 



Parameter 


Definition 


ASN.1 parameter 


observed MSISDN 


Target Identifier with the MSISDN of the target 
subscriber (monitored subscriber) 


Partylnformation/mslSDN 


observed IMSI 


Target Identifier with the IMSI of the target 
subscriber (monitored subscriber) 


Party Information/imsi 


observed IMEI 


Target Identifier with the IMEI of the target 
subscriber (monitored subscriber), it must be 
checked for each call over the radio interface 


Partylnformation/lmei 


event type 


Description which type of event is delivered: 
Establishment, Answer, Supplementary service, 
Handover, Release, SMS, Location update, 
Subscriber controlled input 


There is no one-to-one mapping for this 
information. Parameters presence on HI2 
indicates the event type (e.g. sMS or sclData 
parameter presence) 


event date 


Date of the event generation in the MSC/VLR or 
GMSC 


TimeStamp 


event time 


Time of the event generation in the MSC/VLR 
or GMSC 


dialled number 


Dialled number before digit modification, 
IN-modification, etc. 


Partylnformation (= originating)/DSS1- 
parameters/calledpartynumber 


connected number 


Number of the answering party 


Partylnformation/supplementary-Services-lnfo 


other party address 


Directory number of the other party for 

originating calls 

Calling party for terminating calls 


Partylnformation 

(= terminating)/calledpartynumber 

Partylnformation/callingpartynumber 


call direction 


Information if the monitored subscriber is calling 
or called e.g. MOC/MTC or 
originating/terminating in or/out 


intercepted-Call-Direct 


CID 


Unique number for each call sent to the DF, to 
help the LEA, to have a correlation between 
each call and the IRI (combination of 
Interception Node ID and the correlation 
number) 


communication Identifier 


lawful interception 
identifier 


Unique number for each surveillance lawful 
authorization 


Lawful Interceptionldentifier 


cell id 


Cell number of the target; for the location 
information 


locationOfTheTarget 


location area code 


Location-area-code of the target defines the 
Location Area in a PLMN 


basic service 


Information about Tele service or bearer service 


Partylnformation/DSS1-parameters-codeset-0 


supplementary 
service 


Supplementary services used by the target 
e.g. CF, CW, ECT 


Partylnformation/Supplementary-Services 


forwarded to number 


Forwarded to number at CF 


Partylnformation/calledPartyNumber 
(party-Qualifier indicating forwarded-to-party) 


call release reason 


Call release reason of the target call 


Release-Reason-Of-intercepted-Call 


SMS 


The SMS content with header which is sent with 
the SMS-service 


SMS 


SCI 


Non-call related Subscriber Controlled Input 
(SCI) which the MSC/VLR receives from the ME 


Party 1 nformation/sci Data 


NOTE: LIID parameter must be present in each record sent to the LEMF. 
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A. 9 TETRA technology annex 

Clause A.4 applies to TETRA. 

TETRA intercepted data is defined in EN 301 040 [72] and in the ASN.l module identified below: 

EN301040 {itu-t(O) identif ied-organization (4 ) etsi(O) en301040 (1040) interceptVersion (0) 



A.10 NGN PSTN/ISDN emulation and simulation services 
technology annex 

This clause applies for PSTN/ISDN emulation services and for PSTN/ISDN simulation services which interwork with 
the Circuit Switched telephony network. 

Target identity consists in the target's E.164 Directory Number, TEL_URL and/or SIP_URI. 

A. 10.1 Functional architecture 

The following picture contains a high level functional architecture. TS 187 005 (see bibliography) provides an example 
of a model for NGN PSTN/ISDN emulation and NGN PSTN/ISDN simulation services which could provide a suitable 
example of "source of emulated/simulated PSTN/ISDN". 



Source of 
emulated or 

simulated^ 
PSTN/ISDN) 



Network 

Mediation 

Functionality (MF) 



Law Enforcement 

Monitoring 
Facility (LEMF) 



Handover 
interface 



Figure A.I 0.1 : High ievei functionai archiitecture for PSTN/iSDN emuiation and simuiation services 

A.I 0.2 Correlation 

Clause A.l applies. 

Correlation for IRI and CC delivery is the same as for PSTN/ISDN, meaning via LIID, CID and CCLID used in the 
same way. 

A.10.3 HI2 

IRIs are elaborated and delivered as described in clause A. 3. 

A.10.4 HIS 

CC will be delivered as described in clause A.4. 

Correlation information in HI3 will be delivered as described in clause D.8 and as an option in annex E. 
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Annex B (normative): 

Packet switched network handover 

B.1 Specific identifiers for LI 

Beyond clause 6, at present the Correlation Number as specific LI identifier for packet switched networks is defined. 
The Correlation Number is unique per PDP context and is used for the following purposes: 

• correlate CC with IRI; 

• correlate different IRI records within one PDP context. 

As an example, in the GSM GPRS system, the Correlation Number may be the combination of GGSN address and 
charging ID. 

B.2 HI1 : interface port for administrative state 

There are no additions beyond clause 7. 

B.3 HI2: interface port for IRI 

B.3.1 Definition of Interception Related Information for packet 
switched 

Intercept related information will in principle be available in the following phases of a data transmission: 

1) At connection attempt when the target identity becomes active, at which time packet transmission may or may 
not occur (set up of a data context, target may be the originating or terminating party). 

2) At the end of a connection, when the target identity becomes inactive (removal of a data context). 

3) At certain times when relevant information are available. 

In addition, information on non-transmission related actions of a target constitute IRI and is sent via HI2, 
e.g. information on Subscriber Controlled Input (SCI). 

The Intercept Related Information (IRI) may be subdivided into the following categories: 

4) Control information for HI2 (e.g. correlation information). 

5) Basic data context information, for standard data transmission between two parties. 

B.3. 2 Exception handling 

Exception handling is a national matter. 

B.3. 3 Security aspects 

For security aspects see clause 1 1 . 
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B.4 HIS: interface port for Content of Communication 
(CC) 

Details on the HI3 interface port are described in clause 9. 



B.5 GPRS technology annex 
B.5.1 Functional architecture 

Figure B.5.1 contains the reference configuration for the lawful interception (see 3GPP TS 03.33 [42]). 

There is one ADMinistration Function (ADMF) in the network. Together with the delivery functions it is used to hide 
from the xGSN that there might be multiple activations by different Law Enforcement Agencies (LEAs) on the same 
target identity. 
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NOTE: GGSN interception is a national option. 

Figure B.5.1 : Reference configuration 

The reference configuration is only a logical representation of the entities involved in lawful interception and does not 
mandate separate physical entities. This allows for higher levels of integration. 

A communication could be intercepted based on several identities (MSISDN, IMSI, IMEI) of the same target. 

For the delivery of the CC and IRI the xGSN provides a correlation number and target identity to the DF2P and DF3P 
which is used there to select the different LEAs where the CC/IRI shall be delivered to. 
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B.5.2 Correlation 

B.5.2.1 Correlation of the present document IDs to GSIVI IDs 

The ID Lawful Interception IDentifier (LIID) out of the present document is supported at the IIF (GSM) with warrant 
reference number. 

Parameters from the present document, see clause 6.2. 

Communication IDentifier (CID) 

For each communication or other activity relating to a target identity a CID is generated by the relevant network 
element. The CID consists of the following two identifiers: 

Network IDentifier (NID); 

Communication Identity Number (CIN). 

NOTE: If interception has been activated for both parties of the packet data communication both CC and IRI will 
be delivered for each party as separate intercept activity. 

B. 5.2.2 GPRS LI correlation between CC and IRI 

For the delivery of CC and IRI, the SGSN or GGSN provides correlation numbers and target identities to the HI2 and 
HI3. The correlation number is unique per PDP context and is used to correlate CC with IRI and the different IRIs of 
one PDP context. 

B.5.3 HI2 (delivery of IRI) 

The events defined in 3GPP TS 03.03 [43] are used to generate records for the delivery via HI2. 

There are nine different event types received at DF2 level. According to each event, a record is sent to the LEMF if this 
is required. Table B.5.1 gives the mapping between event type received at DF2 level and record type sent to the LEMF. 

Table B.5.1 : Mapping between GPRS Events and HI2 records type 



Event 


IRI record type 


GPRS attach 


REPORT 


GPRS detach 


REPORT 


PDP context activation (successful) 


BEGIN 


PDP context activation (unsuccessful) 


REPORT 


Start of intercept with PDP context active 


BEGIN or optionally 
CONTINUE 


PDP context modification 


CONTINUE 


PDP context deactivation 


END 


Cell and/or RA update 


REPORT 


SMS 


REPORT 



For some packet oriented data services such as GPRS, the first event of a communication attempt shall be the PDP 
context activation or a similar event and an IRI -BEGIN record shall be issued. The end of the communication attempt 
shall be the PDP context deactivation or a similar event and an IRI-END record shall be issued. While a PDP context is 
active, IRI-CONTINUE records shall be used for CC relevant IRI data records, IRI-REPORT records otherwise. 

For some packet oriented data services such as GPRS, if LI is being activated during an already established PDP 
context or similar, an IRI -BEGIN record will mark the start of the interception. If LI is being deactivated during an 
established PDP context or similar, no IRI-END record will be transmitted. The end of interception can be 
communicated to the LEA by other means (HIl). 

A set of information is used to generate the records. The records used transmit the information from mediation function 
to LEMF. This set of information can be extended in xGSN or DF2P/MF, if this is necessary in a specific country. 
Table B.5.2 gives the mapping between information received per event and information sent in records. 
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Table B.5.2: Mapping between events information and IRI information 



Parameter 


Description 


HI2 ASN.1 parameter 


observed MSISDN 


Target Identifier with the IVISISDN of the target 
subscriber (monitored subscriber) 


Party Information/mslSDN 


observed IMSI 


Target Identifier with the IMSI of the target subscriber 
(monitored subscriber) 


Party Information/imsl 


observed IMEI 


Target Identifier with the IMEI of the target subscriber 
(monitored subscriber) 


Partylnformation/imei 


observed PDP address 


PDP address used by the target 


Partylnformation/pDP-address- 
al located-to-the-target 


event type 


Description which type of event is delivered: PDP 
Context Activation, PDP Context Deactivation, GPRS 
Attach, etc. 


gPRSevent 


event date 


Date of the event generation in the xGSN 


TimeStamp 


event time 


Time of the event generation in the xGSN 


Access point name 


The APN of the access point 


Party Information/aPN 


PDP type 


This field describes the PDP type as defined in 
3GPP TS 09.60 [45], 3GPP TS 04.08 [55], 
TS GSM 09.02 [32] 


Partylnformation/pDP-type 


Correlation number 


Unique number for each PDP context delivered to the 
LEMF, to help the LEA, to have a correlation between 
each PDP Context and the IRI 


gPRSCorrelationNumber 


lawful interception identifier 


Unique number for each lawful authorization 


Lawful Interceptionldentifier 


CGI (Cell Global ID) 


Cell number of the target; for the location information 


locationOfTheTarget/globalCellld 


routing area identifier 


Routing-area-identifier of the target defines the 
Routing Area in a GPRS-PLMN 


locationOfTheTarget/rAI 


SMS 


The SMS content with header which is sent with the 
SMS-service 


SMS 


failed context activation 
reason 


This field gives information about the reason(s) for 
failed context(s) activation of the target subscriber 


gPRSOperationErrorCode 


failed attach reason 


This field gives information about the reason(s) for 
failed attach attempts of the target subscriber 


gPRSOperationErrorCode 


NOTE: LIID parameter must be present in each record sent to the LEMF. 



B.5.4 HIS (Delivery of CC) 

For a GPRS HI3 interface port for Content of Communication (CC) see annex F. 
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Annex C (normative): 

HI2 Delivery mechanisms and procedures 

There are two possible methods for delivery of IRI to the LEMF: 

a) ROSE (see claused); 

b) FTP (see clause C.2). 

According to national requirements at least one of these methods shall be provided. 



C.1 ROSE 
C.1.1 Architecture 



LI_Application 



ASE_HI : 

Application Service Element for 

the Handover Interface 



Session 

Transport 

Network 

Data 

Physical 



Figure C.1.1: Architecture 

The ASE_HI manages the data link, the coding/decoding of the ROSE operations and the sending/receiving of the 
ROSE operations. 

C.1 .2 ASE_HI procedures 
C. 1.2.1 Sending part 

To request the sending of data to a peer entity, the LI_Application provides the ASE_HI, the address of the peer entity, 
the nature of the data and the data. 

On receiving a request of the LI_Application: 

• If the data link toward the peer entity address is active, the ASE_HI, from the nature of the data provided, 
encapsulates this data in the relevant RO-Invoke operation. 

• If the data link toward the peer entity address is not active, the ASE_HI reports the data link unavailability to 
LI_Application. 

NOTE: Until the data link is established by the LI_Application according to clause C.1. 2. 3.1, the request of the 
LI_Application cannot be successfully processed by ASE_HI. 
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Depending on the natures of the data provided by the LI_Application, the ASE_HI encapsulates this data within the 
relevant ROSE operation: 

• LI management notification: in this case the data provided by the application are encoded within the class 2 
RO-Invoke operation "sending-of-HIl -Notification". The ASN.l format is described in clauses D.2 and D.4 
(HIl interface). 

• IRI: in this case the data provided by the application are encoded within the class 2 RO-Invoke operation 
"sending-of-IRI". The ASN.l format is described in clauses D.2 and D.5 (HI2 interface). 

• SMS: in this case the data provided by the application are encoded within the class 2 RO-Invoke operation 
"sending-of-IRI". The ASN.l format is described in clauses D.2 and D.5 (HI2 interface). 

• User packet data transfer (used for data which can be exchanged via ISUP/DSSl/MAP signalling: e.g. UUS): 
in this case the data provided by the application are encoded: 

either within the class 2 RO-Invoke operation "circuit-Call-related-Services" in case of data associated to 
a circuit call (for e.g. UUSl, UUS2, UUS3). The ASN.l format is described in clauses D.2 and D.6 
(HI3 interface); 

or within the class 2 RO-Invoke operation "no-Circuit-Call-related-Services" in case of data not 
associated with a circuit call (for e.g. SMS). The ASN.l format is described in clauses D.2 and D.6 
(HI3 interface). 

• TETRA data transfer: in this case all the information provided by the application are encoded within 
the class 2 RO-Invoke operation "Sending-of-TETRA-Data". The ASN.l format is described in 
clauses D.2 and D.7. 

Depending on the class of the operation, the ASE-HI may have to wait for an answer. In this case a timer, depending on 
the operation, is started on the sending of the operation and stopped on the receipt of an answer (RO_Result, RO_Error, 
RO_Reject). 

On timeout of the timer, the ASE_HI indicates to the LI_Application that no answer has been received. It is under the 
LI_Application responsibility to send again the data or to inform the administrator of the problem. 

On receipt of an answer component (after verification that the component is not erroneous), the ASE_HI stop the 
relevant timer and acts depending on the type of component: 

• On receipt of a RO_Result, the ASE_HI provide the relevant LI_Application an indication that the data has 
been received by the peer LI_Application and the possible parameters contained in the RO_Result. 

• On receipt of a RO_Error, the ASE_HI provide the relevant LI_Application an indication that the data has not 
been received by the peer LI_Application and the possible "Error cause". The error causes are defined for each 
operation in the relevant ASN. 1 script. It is under the LI_Application responsibility to generate or not an alarm 
message toward an operator or administrator. 

• On receipt of a RO_Reject_U/P, the ASE_HI provide the relevant LI_Application an indication that the data 
has not been received by the peer LI_Application and the "Problem cause". The problem causes are defined in 
ITU-T Recommendations X.880 [35] to X.882 [37]. It is under the LI_Application responsibility to send again 
the data or to inform the operator/administrator of the error. 

On receipt of an erroneous component, the ASE_HI acts as described in ITU-T Recommendations X.880 [35] to 
X.882 [37]. 
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C.1.2.2 Receiving part 

On receipt of a ROSE operation from the lower layers: 

• When receiving operations from the peer entity, the ASE_HI verifies the syntax of the component and 
transmits the parameters to the LI_Application. If no error/problem is detected, in accordance with 

the ITU-T Recommendations X.880 [35] to X.882 [37] standard result (only Class2 operation are defined), the 
ASE_HI sends back a RO_Result which coding is determined by the relevant operation ASN.l script. The 
different operations which can be received are: 

RO-Invoke operation "sending-of-HII-Notification" (HIl interface); 

RO-Invoke operation "sending-of-IRI" (HI2 interface); 

RO-Invoke operation "circuit-Call-related-Services" (HI3 interface); 

RO-Invoke operation "no-Circuit-Call-related-Services" (HI3 interface); 

RO-Invoke operation "Sending-of-TETRA-Data" (HI3 interface). 

In case of error, the ASE_HI acts depending on the reason of the error or problem: 

• In accordance with the rules defined by ITU-T Recommendations X.880 [35] to X.882 [37], a RO_Error is 
sent in case of unsuccessfully operation at the application level. The Error cause provided is one among those 
defined by the ASN. 1 script of the relevant operation. 

• In accordance with the rules defined in ITU-T Recommendations X.880 [35] to X.882 [37], a RO_Reject_U/P 
is sent in case of erroneous component. On receipt of an erroneous component, the ASE_HI acts as described 
in ITU-T Recommendations X.880 [35] to X.882 [37]. 

C.1 .2.3 Data linl< management 

This function is used to establish or release a data link between two peer LI_Applications entities (MF and LEMF). 

C.1. 2.3.1 Data link establishment 

Depending on a per destination address configuration data, the data link establishment may be required either by the 
LEMF LI_Application or by the MF LI_Application. 

To request the establishment of a data link toward a peer entity, the LI_Application provides, among others, the 
destination address of the peer entity (implicitly, this address defined the protocol layers immediately under the 
ASE_HI: TCP/IP, X25, etc.). On receipt of this request, the ASE_HI request the establishment of the data link with 
respect of the rules of the under layers protocol. 

As soon as the data link is established, the requesting LI_Application initiates an authentication procedure: 

• The origin LI_Application requests the ASE_HI to send the class 2 RO-Invoke operation 
"sending-of-Password" which includes the "origin password" provided by the LI_Application. 

• The peer LI_Application, on receipt of the "origin password" and after acceptance, requests to its ASE_HI to 
send back a RO_Result. In addition, this destination application requests the ASE_HI to send the class 2 RO- 
Invoke operation "sending-of-Password" which includes the "destination password" provided by the 
LI_Application. 

• The origin LI_Application, on receipt of the "destination password" and after acceptance, requests to its 
ASE_HI to send back a RO_Result. This application is allowed to send data. 

• After receipt of the RO_Result, this application is allowed to send data. 

In case of erroneous password, the data link is immediately released and a "password error indication" is sent toward the 
operator. 
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Optionally a Data link test procedure may be used to verify periodically the data link: 

• When no data have been exchanged during a network dependent period of time toward an address, (may vary 
from 1 minute to 30 minutes) the LI_Application requests the ASE_HI to send the class 2 RO-Invoke 
operation "data-Link-Test". 

• The peer LI_Application, on receipt of this operation, requests to its ASE_HI to send back a RO_Result. 

• On receipt of the Result the test is considered valid by the LI_Application. 

• If no Result is received or if a Reject/Error message is received, the LI_Application requests the ASE_LI to 
release the data link and send an error message toward the operator. 

C.1. 2.3.2 Data link release 

• The End of the connection toward the peer LI_Application is under responsibility of the LI_Application. 
E.g. the End of the connection may be requested in the following cases: 

when all the data (IRI, etc.) has been sent. To prevent unnecessary release, the datalink may be released 
only when no LI_Application data have been exchanged during a network dependent period of time; 

the data link is established when a call is intercepted and released when the intercepted call is released 
(and all the relevant data have been sent); 

for security purposes; 

for changing of password or address of the LEMF/IIF; 

etc. 

• To end the connection a LI_Application requests the ASE_HI to send the class 2 RO-Invoke operation 
"end-of-Connection" . 

• The peer LI_Application, on receipt of this operation, requests to its ASE_HI to send back a RO_Result. 

• On receipt of the Result the LI_Application requests the ASE_LI to release the data link. 

• If no Result is received after a network dependent period of time, or if a Reject/Error message is received, the 
LI_Application requests the ASE_LI to release the data link and to send an error message toward the 
operator/administrator. 

C.1 .2.4 Handling of unrecognized fields and parameters 

See annex G. 



C.1.3 Void 



C.2 FTP 
C.2.1 Introduction 

At HI2 interface FTP is used over Internet protocol stack for the delivery of the IRI. The FTP is defined in 
RFC 959 [46]. The IP is defined in RFC 791 [51]. The TCP is defined in RFC 793 [52]. 

FTP supports reliable delivery of data. The data may be temporarily buffered in the Mediation Function (MF) in case of 
link failure. FTP is independent of the payload data it carries. 



£75/ 



63 



ETSI TS 101 671 V3.1.1 (2007-06) 



C.2.2 Usage of the FTP 



The MF acts as the FTP cHent and the LEMF acts as the FTP server. The chent pushes the data to the server. 

The receiving node LEMF stores the received data as files. The MF may buffer files. 

Several records may be gathered to bigger packages prior to sending, to increase bandwidth efficiency. 

The following configurable intercept data collection (= transfer package closing/file change) threshold parameters 
should be supported: 

• frequency of transfer, based on send timeout, e.g. X ms; 

• frequency of transfer, based on volume trigger, e.g. X octets. 

Every file shall contain only complete IRI records. The single IRI record shall not be divided into several files. 

There are two possible ways how the interception data may be sent from the MF to the LEMF. One way is to produce 
files that contain interception data only for one observed target (ref: "File naming method A)"). The other way is to 
multiplex all the intercepted data that MF receives to the same sequence of general purpose interception files sent by the 
MF (ref: "File naming method B)"). 



File naming: 

The names for the files transferred to a LEA are formed according to one of the two available formats, depending on the 
delivery file strategy chosen (e.g. due to national convention or operator preference). 

Either each file contains data of only one observed target (as in method A) or several targets' data is put to files common 
to all observed target traffic through MF (as in method B). 

The maximum set of allowed characters in interception file names are "a"..."z", "A"..."Z", "-", "_", ".", and decimals 
"0"..."9". 



File naming method A): 
<LIID>_<seq>.<ext> 
where: 



LIID: 



seq = 
ext = 



As defined in the present document clause "Lawful Interception IDentifier (LIID)". This field has 
a character string (or digit string for subaddress option) value, e.g. "ABCD123456". This is a 
unique interception request identifier allocated by the ADMF. It will be given by the ADMF to the 
LEA via the HIl interface after the ADMF has been authorized to command the start of the 
interception of a specific target. The possible network operator identifier part used should be 
agreed with (and allocated by) the regulatory organization administrating the local 
telecommunication practises. 

Integer ranging between [0....2^^"l], in ASCII form (not exceeding 20 ASCII digits), identifying 
the sequence number for file transfer from this node per a specific target. 
ASCII integer ranging between ["!".. ."8"] (in hex: 31H...38H), identifying the file type. The 
possible file types are shown in table C.2.L Type "1" is reserved for IRI data files and type "8" is 
reserved for data files according to a national requirement by using the same file naming concept. 



Table C.2.1 : Possible file types 



File types that the LEA may get 


Intercepted data types 


"1" (in binary: 0011 0001) 


IRI 


"8" (in binary: 001 1 1000) 


for national use 



This alternative A is used when each target's IRI is gathered per observed target to dedicated delivery files. This method 
provides the result of interception in a very refined form to the LEAs, but requires somewhat more resources in the MF 
than alternative B. With this method, the data sorting and interpretation tasks of the LEMF are considerably easier to 
facilitate in near real time than in alternative B. 
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File naming metlnod B): 

The other choice is to use monoHthic fixed format file names (with no trailing file type part in the file name): 

<filenamestring> of the format ABXYyymmddhhmmsseeeet 
where: 



AB = 
XY = 

yy = 

mm = 
dd = 
hh = 
mm = 

ss = 
eeee = 



Two letter ASCII Operator ID (as agreed with the national telecom regulators). 
Two letter ASCII identification of the MF node (as assigned by the operator). 



Two digits ASCII integer ranging between ["00" 
Two digits ASCII integer ranging between ["01" 
Two digits ASCII integer ranging between ["01" 
Two digits ASCII integer ranging between ["00" 
Two digits ASCII integer ranging between ["00" 
Two digits ASCII integer ranging between ["00" 



"99"], identifying the last two digits of the year. 

"12"], identifying the month. 

"31"], identifying the day. 

"23"], identifying the hour. 

"59"], identifying the minute. 

"59"], identifying the second. 



Alphanumeric extension made up of four characters chosen at the discretion of the Operator and/or 
the MF to avoid file name clashes within the MF. Each of the position shall be out of "A"..."Z", 

ASCII integer ranging between ["1"..."8"] (in hex: 31H...38H), identifying the file type. The 
possible file types are shown in table C.2.1. Type "1" is reserved for IRI data files and type "8" is 
reserved for data files according to a national requirement by using the same file naming concept. 



EXAMPLE: <filenamestring> (e.g. ABXY00041 014084400001) 

where: 

ABXY = source node identifier part, used for all files by the mobile network operator "AB" from this MF 

node named "XY". 

00 = year 2000. 

04 = month April. 

10 = day 10. 

14 = hour. 

08 = minutes. 

44 = seconds. 

0000 = extension. 

1 = file type. The type "1" is reserved for IRI data files and type "8" is reserved for national use. 

(Codings "2" = CC(MO), "4" = CC(MT), "6" = CC(MO&MT) are reserved for HI3). 

This alternative B is used when several targets' intercepted data is gathered to common delivery files. This method does 
not provide the result of interception in as refined form to the LEAs as the alternative A, but it is faster in performance 
for the MF point of view. With this method, the MF does not need to keep many files open like in alternative A. 

C.2.3 Profiles 

NOTE: This clause is informative only. 

As there are several ways (usage profiles) how data transfer can be arranged by using the FTP, this clause contains 
practical considerations how the communications can be set up. Guidance is given for client-server arrangements, 
session establishments, time outs, the handling of the files (in RAM or disk). Example batch file is described for the 
case that the sending FTP client uses files. If instead (logical) files are sent directly from the client's RAM memory, 
then the procedure can be in principle similar though no script file would then be needed. 
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At the LEMF side, FTP server process is run, and at MP, FTP client. No FTP server (which could be accessed from 
outside the operator network) shall run in the MF. The FTP client can be implemented in many ways, and here the FTP 
usage is presented with an example only. The FTP client can be implemented by a batch file or a file sender program 
that uses FTP via an API. The login needs to occur only once per e.g. <destaddr> and <leauser> - pair. Once the login is 
done, the files can then be transferred just by repeating "mput" command and checking the transfer status (e.g. from the 
API routine return value). To prevent inactivity timer triggering, a dummy command (e.g. "pwd") can be sent every 
T seconds (T should be less than L, the actual idle time limit). If the number of FTP connections is wanted to be as 
minimized as possible, the FTP file transfer method "B" is to be preferred to the method A (though the method A helps 
more the LEMF by pre-sorting the data sent). 

Simple example of a batch file extract: 

FTP commands usage scenario for transferring a list of files: 

To prevent FTP cmd line buffer overflow the best way is to use wildcarded file names, and let the FTP implementation 
do the file name expansion (instead of shell). The number of files for one mput is not limited this way: 

ftp <flags> <destaddr> 

user <leauser> <leapasswd> 

cd <destpath> 

led <srcpath> 

bin 

mput <files> 

nlist <lastfile> <checkfile> 

close 
EOF 

This set of commands opens an FTP connection to a LEA site, logs in with a given account (auto-login is disabled), 
transfers a list of files in binary mode, and checks the transfer status in a simplified way. 

Brief descriptions for the FTP commands used in the example: 

user <user-name> <password> Identify the client to the remote FTP server. 

cd <remote-directory> Change the working directory on the remote machine to 

remote-directory . 
led <directory> Change the working directory on the local machine, 

bin Set the file transfer type to support binary image transfer 

mput <local-f iles> Expand wild cards in the list of local files given as 

arguments and do a put for each file in the resulting list. 

Store each local file on the remote machine, 
nlist <remote-directory> <local-file> Print a list of the files in a directory on the remote 

machine. Send the output to local-file. 
close Terminate the FTP session with the remote server, and return 

to the command interpreter. Any defined macros are erased. 

The parameters are as follows: 

<flags> contains the FTP command options, e.g. "-i -n -V -p" which equals to "interactive prompting off", "auto-login 
disabled", "verbose mode disabled", and "passive mode enabled". (These are dependent on the used ftp-version.) 

«lestaddr> contains the IP address or DNS address of the destination (LEA) 

<leauser> contains the receiving (LEA) username 

<leapasswd> contains the receiving (LEA) user's password 

<destpath> contains the destination path 

<srcpath> contains the source path 

<files> wild carded file specification (matching the files to be transferred) 

<lastfile> the name of the last file to be transferred 

<checkfile> is a (local) file to be checked upon transfer completion; if it exists then the transfer is considered successful 

The FTP application should to do the following things if the check file is not found: 

• keep the failed files; 
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• raise "file transfer failure" error condition (i.e. send alarm to the corresponding LEA); 

• the data can be buffered for a time that the buffer size allows. If that would finally be exhausted, DF would 
start dropping the corresponding target's data until the transfer failure is fixed; 

• the transmission of the failed files is retried until the transfer eventually succeeds. Then the DF would again 
start collecting the data; 

• upon successful file transfer the sent files are deleted from the DF. 

The FTP server at LEMF shall not allow anonymous login of an FTP client. 

It is required that FTP implementation guarantees that LEMF will start processing data only after data transfer is 
complete. 

The following implementation example addresses a particular issue of FTP implementation. It is important however to 
highlight that there are multiple ways of addressing the problem in question, and therefore the given example does not 
in any way suggest being the default one. 

• MF sends data with a filename, which indicates that the file is temporary. Once data transfer is complete, MF 
renames temporary file into ordinary one (as defined in clause C.2.2). 

The procedure for renaming filename should be as follow: 

1) open FTP channel (if not already open) from MF to LEMF; 

2) sends data to LEMF using command "put" with temporary filename; 

3) after MF finished to send the file, renaming it as ordinary one with command "ren". 
Brief descriptions for the FTP commands used in the example: 

ren <from-name> <to-name> renaming filename from-name to to-name. 

If the ftp-client want to send file to LEMF using the command "mput" (e.g. MF stored many IRI files and want 
to send all together with one command), every filename transferred successfully must be renamed each after 
command "mput" ended. 

C.2.4 File content 

The file content is in method A relating to only one intercepted target. 

In the file transfer method B, the file content may relate to any intercepted targets whose intercept records are sent to 
the particular LEMF address. 

Individual IRI records shall not be fragmented into separate files at the FTP layer. 

C.2.5 Exceptional procedures 

Overflow at the receiving end (LEMF) is avoided due to the nature of the protocol. 

In case the transit network or receiving end system (LEMF) is down for a reasonably short time period, the local 
buffering at the MF will be sufficient as a delivery reliability backup procedure. 

In case the transit network or receiving end system (LEMF) is down for a very long period, the local buffering at the 
MF may have to be terminated. Then the following intercepted data coming from the intercepting nodes to the MF 
would be discarded, until the transit network or LEMF is up and running again. 
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C.2.6 Other considerations 

The FTP protocol mode parameters used: 

• Transmission Mode: stream 

• Format: non-print 

• Structure: file-structure 

• Type: binary 

The FTP client (= user-FTP process at the MF) uses e.g. the default standard FTP ports 20 (for data connection) and 21 
(for control connection), "passive" mode is supported. The data transfer process listens the data port for a connection 
from a server-FTP process. 

For the file transfer from the MF to the LEMF(s) e.g. the following data transfer parameters are provided for the FTP 
client (at the MF): 

transfer destination (IP) address, e.g. "194.89.205.4"; 

transfer destination username, e.g. "LEAl"; 

transfer destination directory path, e.g. "/usr/local/LEAl/1234-829r'; 

transfer destination password; 

interception file type, "1" (this is needed only if the file naming method A is used). 

LEMF may use various kind directory structures for the reception of interception files. It is strongly recommended that 
at the LEMF machine the structure and access and modification rights of the storage directories are adjusted to prevent 
unwanted directory operations by a FTP client. 

Timing considerations for tine HI2 FTP transmission: 

The MF and LEMF sides control the timers to ensure reliable, near-real time data transfer. The transmission related 
timers are defined within the lower layers of the used protocol and are out of scope of the present document. 

The following timers may be used within the LI application. 

Table C.2.2: Timing considerations 



Name 


Controlled by 


Units 


Description 


T1 inactivity timer 


LEMF 


Seconds 


Triggered by no activity within the FTP session (no new files). 
The FTP session is torn down when the T1 expires. To send 
another file the new connection will be established. The timer 
avoids the FTP session overflow at the LEMF side. 


T2 send file trigger 


MF 


Milliseconds 


Forces the file to be transmitted to the LEMF (even if the size 
limit has not been reached yet in case of volume trigger active). If 
the timer is set to the only trigger to send the file is the file size 
parameter (see clause C.2.2). 
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Annex D (normative): 

Structure of data at the Handover Interface 

This annex specifies the coding details at the Handover Interface HI for all data, which may be sent from the 
NWO/AP/SvP's equipment to the LEMF, across HI. 

At the three Handover Interface (HI) ports, the following data may be present: 

• interface port HIl: Interception administration information; 

• interface port HI2: Intercept Related Information (IRI); 

• interface port HI3: records containing Content of Communication (CC). 

The detailed coding specification for these types of information is contained in this annex, including sufficient details 
for a consistent implementation in the NWO/AP/SvP's equipment and the LEMF. 

It must be noticed some data are ROSE specific and have no meaning when FTP is used. Those specificities are 
described at the beginning of each clause (D.3, D.4, D.5 and D.6). 



D.1 Syntax definitions 



The transferred information and messages are encoded to be binary compatible with 

ITU-T Recommendations X.680 [33] (Abstract Syntax Notation One (ASN.l)) and X.690 [34] (Basic Encoding Rules 

(BER)). 

These recommendations use precise definitions of the words type, class, value, and parameter. Those definitions are 
paraphrased below for clarity. 

A type, in the context of the abstract syntax or transfer syntax, is a set of all possible values. For example, an INTEGER 
is a type for all negative and positive integers. 

A class, in the context of the abstract syntax or transfer syntax, is a one of four possible domains for uniquely defining a 
type. The classes defined by ASN.l and BER are: UNIVERSAL, APPLICATION, CONTEXT, and PRIVATE. 

The UNIVERSAL class is reserved for international standards such as ITU-T Recommendations X.680 [33] and 
X.690 [34]. Most parameter type identifiers in the HI ROSE operations are encoded as CONTEXT specific class. Users 
of the protocol may extend the syntax with PRIVATE class parameters without conflict with the present document, but 
risk conflict with other users' extensions. APPLICATION class parameters are reserved for future extensions. 

A value is a particular instance of a type. For example, five (5) is a possible value of the type INTEGER. 

A parameter in the present document is a particular instance of the transfer syntax to transport a value consisting of a 
tag to identify the parameter type, a length to specify the number of octets in the value, and the value. 

In the BER a tag (a particular type and class identifier) may either be a primitive or a constructor. A primitive is a 
pre-defined type (of class UNIVERSAL) and a constructor consists of other types (primitives or other constructors). A 
constructor type may either be IMPLICIT or EXPLICIT. An IMPLICIT type is encoded with the constructor identifier 
alone. Both ends of a communication must understand the underlying structure of the IMPLICIT types. EXPLICIT 
types are encoded with the identifiers of all the contained types. For example, an IMPLICIT Number of type INTEGER 
would be tagged only with the Number tag, where an EXPLICIT number of type INTEGER would have the INTEGER 
tag within the Number tag. The present document uses IMPLICIT tagging for more compact message encoding. 

For the coding of the value part of each parameter the general rule is to use a widely use a standardized format when it 
exists (ISUP, DSSl, MAP, etc.). 

As a large part of the information exchanged between the users maybe transmitted within ISUP/DSSl signalling, the 
using of the coding defined for this signalling guarantee the integrity of the information provided to the LEMF and the 
evolution of the interface. For example if new values are used within existing ISUP parameters, this new values shall be 
transmitted transparently toward the LEMF. 
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For the ASN.l parameters of the type "OCTET STRING", the ordering of the individual halfoctets of each octet shall 
be such that the most significant halfoctet is put into bit position 5 to 8 and the least significant halfoctet into bit 
position 1 to 4. This general rule shall not apply when parameter formats are imported from other standards, e.g. an 
E.164 number coded according to ISUP (ITU-T Recommendation Q.763 [48]). In this case the ordering of the halfoctet 
shall be according to that standard and not be changed. 



D.2 Object tree 



itu-t(0) 



identified-orgaiiization (4) 



'-.' specific version 




etsi(O) 



secmityDomam(2) 



lawfullnten;ept(2) 



[TS 101 909-20', ,.- 



subpart(l) 



subpart(2) 



7\ TV 






S 102232-1) 



[section I 



[section D. 7[ [section 



gPRSU(3) 



[section D.HJJ 





Figure D.2.1 : Object Tree: Lawful Interception in ETSI domain 



TR 102 503 (see bibliography) describes the structure for the ETSI domain with the included Lawful Intercept (LI) 
domain and ASN. 1 modules from other Lawful Interception specifications in detail. It gives an overview over all the 
relevant Object IDentifiers (OID) used in ASN.l modules of the Lawful Intercept specifications and point to the 
specification where the modules can be found. 
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D.3 HI management operation 

This data description applies only for ROSE delivery mechanism. 

ASN.1 description of IHI management operation (any l-ll interface) 

HIManagementOperations 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2 ) him(3) 
versions (3) } 

DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 



EXPORTS sending-of-Password, 

data-Link-Test , 
end-Of -Connect ion ; 



IMPORTS OPERATION, 




ERROR 




FROM Remote-Ope rat ions -Information-Objects 




{ joint-iso-itu-t (2) remote-operations (4) informationOb jects (5) 


versionl (0) } ; 



— Object Identifier definitions 

— Lawfullntercept Domainid 

lawfulInterceptDomainld OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(C 
securityDomain (2) lawfullntercept (2) } 

— him Domain 

himDomainld OBJECT IDENTIFIER ::= {lawfulInterceptDomainld him(3)} 
himOperationId OBJECT IDENTIFIER ::= {himDomainld versions (3)} 



sending-of-Password OPERATION ::= 
{ 

ARGUMENT Password-Name 

ERRORS {ErrorsHim} 

CODE global : {himDomainld sending-of-Password ( 1 ) versionl (1)} 
} 

— Class 2 operation. The timer must be set to a value between 3s and 240s. 

— The timer default value is 60s. 



data-Link- 


rest 


OPERATION : : = 
















ERRORS 


{ other- failure- causes } 
















CODE 


global ; {himDomainld data 


-link- 


test (2) 


versionl ( 1 ) } 






— Class 2 


operation 


The timer must be 


set 


tc 


a 


value 


between 3s 


and 


240s. 


— The timer default 


value is 60s . 

















end-Of -Connect ion 


OPERATION : := 


















ERRORS 


{other-failure-causes } 


















CODE 


global : {himDomainld end- 


-of- 


connection 


(3) 


versionl (1) } 




— Class 2 


operation 


The timer must be 


set 


to 


a 


value b 


etween 


3s and 


240s. 


— The timer default 


value is 60s . 



















other- failure- causes 


ERROR : 


= {CODE local: 0} 


missing-parameter 


ERROR : 


= {CODE local:!} 


unknown-parameter 


ERROR : 


= {CODE local: 2} 


erroneous-parameter 


ERROR : 


= {CODE local: 3} 


ErrorsHim 


ERROR : 


= 


other-failure-causes I 




missing-parameter | 






unknown-parameter | 






erroneous-parameter 

} 
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Password-Name : : = SEQUENCE 

{ 

domainID [0] OBJECT IDENTIFIER (himOperationId) OPTIONAL, 

— Once using FTP delivery mechanism 

password [1] OCTET STRING (SIZE (1..25)), 

name [2] OCTET STRING (SIZE (1..25)), 



— IA5 string recommended 



END — end of HIManagementOperations 



D.4 LI management notification 



Declaration of ROSE operation "sending-of-HIl-Notification" is ROSE delivery mechanism specific. When using FTP 
delivery mechanism, data HI 1 -Operation must be considered. 

NOTE: This annex does not describe an electronic Handover Interface, but HI I information, which is sent to the 
LEMF across the HI2 port. 

ASN.1 description of LI management notification operation (I-II1 interface) 

HIlNotificationOperations 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hil(O) 
notif icationOperations (1) versions (5) } 

DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 

IMPORTS 

OPERATION, 
ERROR 

FROM Remote-Ope rat ions -Information-Objects 

( joint-iso-itu-t (2 ) remote-operations (4) inf ormationOb jects (5 ) versionl(O)} 

— from clause D.5 
Communicationldentifier, 
TimeStamp, 
Lawfullnterceptionldentifier 

FROM HI20perations 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi2(l) 
versionlO (10) }; 



— Object Identifier Definitions 

— Lawfullntercept Domainid 

lawfulInterceptDomainld OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(O) 
securityDomain (2) lawfullntercept (2) } 

— hil Domain 

hilNotificationOperationsId OBJECT IDENTIFIER ::= { lawfulInterceptDomainld hil (0 ) 

notif icationOperations (1) } 

hilOperationId OBJECT IDENTIFIER ::= {hilNotificationOperationsId versions (5)} 

sending-of-HIl-Notification OPERATION ::= 
{ 

ARGUMENT HI 1-Operat ion 

ERRORS {ErrorHIlNotifications} 

CODE global ; (hilNotificationOperationsId versionl(l)} 
} 

— Class 2 operation. The timer shall be set to a value between 3s and 240s. 

— The timer default value is 60s. 

— NOTE; The value for this timer is to be set on the equipment waiting for the returned message; 

— its value shall be agreed between the NWO/AP/SvP and the LEA, depending on their equipment 

— properties. 
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other- failure- causes 


ERROR : 


= (CODE local: 0} 


missing-parameter 


ERROR : 


= (CODE local:!} 


unknown-parameter 


ERROR : 


= (CODE local: 2} 


erroneous-parameter 


ERROR : 


= (CODE local: 3} 


ErrorHIlNotifications 


ERROR : : = 




other-failure-causes I 




missing-parameter 


1 




unknown-parameter 


1 




erroneous-parameter 

} 





Hll-Operation ::= CHOICE 
{ 

liActivated 

liDeactivated 

liModified 

alarms-indicator 



national-HIl-ASNlparameters 



[1] Notification, 

[2] Notification, 

[3] Notification, 

[4] Alarm-Indicator, 

[5] National-HIl-ASNlparameters 



PARAMETERS FORMATS 



Notification 



SEQUENCE 



domainID [0] OBJECT IDENTIFIER (hilOperationId) OPTIONAL, 

— Once using FTP delivery mechanism 
lawfullnterceptionldentifier [1] Lawfullnterceptionldentif ier, 

— This identifier is the LIID identity provided with the lawful authorization 

— for each target . 

communicationldentifier [2] Communicationldentif ier OPTIONAL, 

— Only the NWO/PA/SvPIdentif ier is provided (the one provided with the Lawful 

— authorization) . 

— Called "callldentifier" in VI . 1 . 1 of ES 201 671 (see bibliography). 
timeStamp [3] Time St amp, 

— date and time of the report. 



national-HIl-ASNlparameters 



[5] National-HIl-ASNlparameters OPTIONAL 



Alarm-Indicator 



: : = SEQUENCE 



domainID [0] OBJECT IDENTIFIER (hilOperationId) OPTIONAL, 

— Once using FTP delivery mechanism 
communicationldentifier [1] Communicationldentifier OPTIONAL, 

— Only the NWO/PA/SvPIdentif ier is provided (the one provided with the 

— Lawful authorization) 

timeStamp [2] TimeStamp, 

— date and time of the report. 

alarm-information [3] OCTET STRING (SIZE (1..25)), 

— Provides information about alarms (free format) . 

lawfullnterceptionldentifier [4] Lawfullnterceptionldentifier OPTIONAL, 

— This identifier is the LIID identity provided with the lawful authorization 

— for each target in according to national law. 
national-HIl-ASNlparameters [5] National-HIl-ASNlparameters OPTIONAL 
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National-HIl-ASNlparameters : := SEQUENCE 

{ 

domainID [0] OBJECT IDENTIFIER (hilOperationId) OPTIONAL, 

— Once using FTP delivery mechanism. 
countryCode [1] PrintableString (SIZE (2) ) , 

— Country Code according to ISO 3166-1 [67], 

— the country to which the parameters inserted after the extension marker apply. 

— In case a given country wants to use additional national parameters according to its law, 

— these national parameters should be defined using the ASN . 1 syntax and added after the 

— extension marker (...). 

— It is recommended that "version parameter" and "vendor identification parameter" are 

— included in the national parameters definition. Vendor identifications can be 

— retrieved from lANA web site (see annex H) . Besides, it is recommended to avoid 

— using tags from 240 to 255 in a formal type definition. 



END — end of HIlNotif icationOperations 



D.5 Intercept related information (HI2 PS and CS) 

Declaration of ROSE operation "sending-of-IRI" is ROSE delivery mechanism specific. When using FTP delivery 
mechanism, data IRIsContent must be considered. 

ASN.1 description of IRI (HI2 interface) 

HI20perations 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi2(l) 
versionlO (10) } 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 

IMPORTS OPERATION, 
ERROR 

FROM Remote-Ope rat ions -Information-Objects 

{ joint-iso-itu-t (2 ) remote-operations (4) informationObjects (5) versionl(O)} 

— from 3GPP TS 33.108 [61] 
UmtsQos, 

IMSevent , 
LDIevent, 
CorrelationValues 

FROM UmtsHI20perations 

{itu-t(O) identif ied-organization (4) etsi(O) securityDomain (2) lawfullntercept (2) 
threeGPP(4) hi2(l) r7(7) version-3 (3 ) } 

— from TS 101 909-20-01 [69] 
TARGETACTIVITYMONITOR-1 

FROM TS101909201 

{itu-t(O) identified-organization (4) etsi(O) tsl01909 (1909) part20(20) subpartl(l) 
intercept Version ( ) } 

— from EN 301 040 [72] 
TARGETACTIVITYMONITORind, 
TARGETCOMMSMONITORind, 
TTRAFFICind, 
CTTRAFFICind 

FROM EN301040 

iitu-t(O) identified-organization (4) etsi(O) en301040 (1040) intercept Version (0)}; 
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Object Identifier Definitions 



— Lawfullntercept Domainld 

lawfulInterceptDomainld OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(O) 
securityDomain (2) lawfullntercept (2) } 

— Security Subdomains 

hi2DomainId OBJECT IDENTIFIER ::= { lawfulInterceptDomainld hi2 ( 1 ) } 
hi20perationld OBJECT IDENTIFIER ::= {hi2DomainId versionlO ( 10 ) } 



sending-of-IRI OPERATION ::= 
{ 

ARGUMENT IRIsContent 
ERRORS {OperationErrors} 

CODE global: {hi2DomainId sending-of-IRI ( 1 ) versionl(l)} 
} 

— Class 2 operation. The timer shall be set to a value between 3s and 240s. 

— The timer default value is 60s. 

— NOTE: The same note as for HI management operation applies. 



IRIsContent ::= CHOICE 

{ 

iRIContent IRIContent, 

iRISequence IRISequence 



IRISequence ::= SEQUENCE OF IRIContent 

— Aggregation of IRIContent is an optional feature. 

— It may be applied in cases when at a given point in time several IRI records are 

— available for delivery to the same LEA destination. 

— As a general rule, records created at any event shall be sent immediately and shall 

— not held in the DF or MF in order to apply aggregation. 

— When aggregation is not to be applied, IRIContent needs to be chosen. 



IRIContent ::= CHOICE 














iRI-Begin-record 


[1] IRI-Parameters, 














— At least one 


optional parameter must 


be 


included 


within 


the 


IRI- 


-Begin-Record. 


iRI-End-record 


[2] IRI-Parameters, 














iRI-Continue-record 


[3] IRI-Parameters, 














— At least one 


optional parameter must 


be 


included 


within 


the 


IRI- 


-Continue-Record. 


iRI-Report-record 


[4] IRI-Parameters, 














— At least one 
} 


optional parameter must 


be 


included 


within 


the 


iRI- 


-Report-Record. 



unknown-version ERROR : 
missing-parameter ERROR : 
unknown-parameter-value ERROR : 
unknown-parameter ERROR : 


= (CODE 
= (CODE 
= (CODE 
= (CODE 


local 
local 
local 
local 


0} 

1} 

2} 
3} 






OperationErrors ERROR ::= 












unknown-version | 
missing-parameter | 
unknown-parameter- value | 
unknown-parameter 












— These values may be sent by " 


.he LEMF, 


when 


an 


operation or a parameter 


is misunderstood. 
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IRI— Parameters 



SEQUENCE 



domainID [0] OBJECT IDENTIFIER (hi20perationId) OPTIONAL, 

— for the sending entity the inclusion of the Object Identifier is mandatory 
iRIversion [23] ENUMERATED 

{ 

version2 (2) , 



versions (3) 
version4 (4) 
versions (5) 
versions (6) 
version? (7) 
lastVersion ( 8 ) 
} OPTIONAL, 

— Optional parameter 



— where to the object identifier 



is redundant starting from TS 101 671 v2 . 4 . 1 

was introduced into IRI-Parameters . 
even when the version of the "domainID" 



'iRIversion" (tag 23) 
"domainID 

— In order to keep backward compatibility, 

— parameter will be incremented it is recommended to always send to LEMF the same 

— enumeration value "lastVersion (8) " . 

— if not present, it means version 1 is handled 
lawfullnterceptionldentifier [1] Lawfullnterceptionldentif ier, 

— This identifier is associated to the target. 
communicationldentifier [2] Communicationldentif ier, 

— used to uniquely identify an intercepted call. 

— Called "callldentifier" in VI . 1 . 1 of ES 201 671 (see bibliograhy) . 
timeStamp [3] Time St amp, 

— date and time of the event triggering the report. 
intercepted-Call-Direct [ 4 ] ENUMERATED 



not -Available ( ) , 
originating-Target (1) , 

— In case of GPRS, this indicates that the PDP context activation, modification 

— or deactivation is MS requested. 
terminating-Target (2) , 

— In case of GPRS, this indicates that the PDP context activation, modification 

— or deactivation is network initiated. 



Intercepted-Call-State OPTIONAL, 

OCTET STRING (SIZE (3)) OPTIONAL, 

HHMMSS 

OCTET STRING (SIZE (3) 

HHMMSS 

Location OPTIONAL, 



OPTIONAL, 



} OPTIONAL, 

intercepted-Call-State [5] 

ringingDuration [6] 

— Duration in seconds. BCD coded : 
conversationDuration [7] 

— Duration in seconds. BCD coded 
locationOf TheTarget [ 8 

— location of the target subscriber 

partylnformation [9] SET SIZE (1..10) OF Partylnformation OPTIONAL, 

— This parameter provides the concerned party (Originating, Terminating or forwarded 

— party), the identity (ies) of the party and all the information provided by the party. 
callContentLinklnformation [10] SEQUENCE 

{ 

cCLinklCharacteristics [1] CallContentLinkCharacteristics OPTIONAL, 

— Information concerning the Content of Communication Link Tx channel established 

— toward the LEMF (or the sum signal channel, in case of mono mode) . 
cCLin]c2Characteristics [2] CallContentLinkCharacteristics OPTIONAL, 

— Information concerning the Content of Communication Link Rx channel established 

— toward the LEMF. 



} OPTIONAL, 

release-Reason-Of-Intercepted-Call [11] OCTET STRING (SIZE (2)) OPTIONAL, 

— Release cause coded in ITU-T Q.850 [31] format. 

— This parameter indicates the reason why the intercepted call cannot be established or 

— why the intercepted call has been released after the active phase. 
nature-Of-The-intercepted-call [12] ENUMERATED 

{ 

— Nature of the intercepted "call": 
gSM-ISDN-PSTN-circuit-call (0) , 

— the possible UUS content is sent through the HI2 or HI3 "data 

— the possible call content call is established through the HI3 
gSM-SMS-Message ( 1 ) , 

— the SMS content is sent through the HI2 or HI3 "data" interface 
uUS4-Messages (2) , 

— the UUS content is sent through the HI2 or HI3 "data" interface 
tETRA-circuit-call ( 3 ) , 

— the possible call content call is established through the HI3 "circuit" interface 

— the possible data are sent through the HI3 "data" interface 
teTRA-Packet-Data ( 4 ) , 

— the data are sent through the HI3 "data" interface 



interface 
circuit" interface 
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gPRS-Packet-Data ( 5 ) , 

— the data are sent through the HIS "data" interface 

uMTS-circuit-call ( 6 ) 

— the possible call content call is established through the HI3 "circuit" interface 

— the possible data are sent through the HI3 "data" interface 
} OPTIONAL, 

serverCenterAddress [13] Partylnformation OPTIONAL, 

— e.g. in case of SMS message this parameter provides the address of the relevant 

— server within the calling (if server is originating) or called 

— (if server is terminating) party address parameters 
sMS [14] SMS-report OPTIONAL, 

— this parameter provides the SMS content and associated information 
cC-Link-Identifier [15] CC-Linlt-Identif ier OPTIONAL, 

— Depending on a networlc option, this parameter may be used to identify a CC linlc 

— in case of multiparty calls. 

national-Parameters [16] National-Parameters OPTIONAL, 

gPRSCorrelationNiraiber [18] GPRSCorrelationNumber OPTIONAL, 

gPRSevent [20] GPRSEvent OPTIONAL, 

— This information is used to provide particular action of the target 

— such as attach/detach 

sgsnAddress [21] DataNodeAddress OPTIONAL, 

gPRSOperationErrorCode [22] GPRSOperationErrorCode OPTIONAL, 



ggsnAddress [24] 

qOS [25] 

— This parameter is duplicated from 
networkldentifier [26] 

— This parameter is duplicated from 
sMSOriginatingAddress [27] 

— This parameter is duplicated from 
sMSTerminatingAddress [28] 

— This parameter is duplicated from 
iMSevent [29] 
sIPMessage [30] 

— This parameter is duplicated from 
servingSGSN-number [31] 

— This parameter is duplicated from 
servingSGSN-address [32] 

— Octets are coded according to TS 1 

— This parameter is duplicated from 
tARGETACTIVITYMONITOR [33] 

— Parameter is used in TS 101 909-20 
IdiEvent [34] 

— The "Location Dependent Intercepti 
correlation [35] 

— This parameter is duplicated from 
tARGETACTIVITYMONITORind [36] 

— Parameter is used in EN 301 040 [7 
tARGETCOMMSMONITORind [37] 

— Parameter is used in EN 301 040 [7 
tTRAFFICind [38] 

— Parameter is used in EN 301 040 [7 
cTTRAFFICind [39] 

— Parameter is used in EN 301 040 [7 
national-HI2-ASNlparameters [255] 



DataNodeAddress OPTIONAL, 
UmtsQos OPTIONAL, 
3GPP TS 33.108 [61] . 
Network-Identifier OPTIONAL, 
3GPP TS 33.108 [61] . 
DataNodeAddress OPTIONAL, 
3GPP TS 33.108 [61] . 
DataNodeAddress OPTIONAL, 
3GPP TS 33.108 [61] . 
IMSevent OPTIONAL, 
OCTET STRING OPTIONAL, 
3GPP TS 33.108 [61] . 

OCTET STRING (SIZE (1..20)) OPTIONAL, 
3GPP TS 33.108 [61] . 

OCTET STRING (SIZE (5.. 17)) OPTIONAL, 
23 003 

3GPP TS 33.108 [61] . 
TARGETACTIVITYMONITOR- 1 OPTIONAL, 
-1 [69] 

LDIevent OPTIONAL, 

on" parameter is duplicated from 3GPP TS 33.108 [61] 
CorrelationValues OPTIONAL, 
3GPP TS 33.108 [61] 

TARGETACTIVITYMONITORind OPTIONAL, 
2] 

TARGETCOMMSMONITORind OPTIONAL, 
2] 

TTRAFFICind OPTIONAL, 
2] 

CTTRAFFICind OPTIONAL, 
2] 
National-HI2-ASNlparameters OPTIONAL 
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PARAMETERS FORMATS 



Communicationldentif ier : : = SEQUENCE 

{ 

communication-Identity-Niraiber [0] OCTET STRING (SIZE (1..8)) OPTIONAL, 

— Temporary Identifier of an intercepted call to uniquely identify an intercepted call 

— within the node. This parameter is mandatory if there is associated 

— information sent over HISinterface (CClink, data, . . ) or when 

— Communicationldentif ier is used for IRI other than IRI-Report-record 

— This parameter was called "call-Identity-Number" in VI . 1 . 1 of ES 201 671 (see 

bibliography) . 

— The individual digits of the communication-Identity-Number shall be represented in 

— ASCII format, e.g. "12345678" = 8 octets 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38. 
network— Identifier [1] Network-Identifier, 

} 

— NOTE; The same "Communicationldentif ier " value is sent ; 

— with the HI3 information for correlation purpose between the IRI and the information sent on 

— the HI3 interfaces (CCLink, data, . . ) with each IRI associated to a same intercepted call 

— for correlation purpose between the different IRI. 



Network-Identifier : : = SEQUENCE 
{ 

operator-Identifier [0] OCTET STRING (SIZE (1..5)), 

— It is a notification of the NWO/AP/SvP in ASCII- characters. 

— The parameter is mandatory. 
network-Element-Identifier [1] Network-Element-Identif ier OPTIONAL, 



Network-Element-Identifier ::= CHOICE 
{ 

el64-Format [1] OCTET STRING (SIZE (1..25)), 

— E164 address of the node in international format. Coded in the same format as the 

— calling party number parameter of the ISUP (parameter part: EN 300 356 [5]) . 
x25-Format [2] OCTET STRING (SIZE (1..25)), 

— X25 address 

iP-Format [3] OCTET STRING (SIZE (1..25)), 

— IP address 

dNS-Format [4] OCTET STRING (SIZE (1..25)), 

— DNS address 

iP-Address [5] IPAddress 



cc- 


-Link-Identifier 






:= OCTET 


STRING (SIZE 


(1. .8) 


) 
















— Depending on 


a 


net 


work option. 


this paramet 


er may 


be used 


to 


ident 


if y a 


CCl 


ink 






— in case of mult 


ipa 


rty calls. 






















— The individual 


dig 


its of the communication- 


Identit 


y-Numbei 


shall b 


e rep 


rese 


nted 


in 




— ASCII format. 


e 


■ g- 


"12345678" 


= 8 octets Ox 


31 0x32 


0x33 Ox 


34 


0x35 


0x36 


0x37 


0x38 





TimeStamp ::= CHOICE 

{ 

— The minimum resolution required is one second. 

— "Resolution" is the smallest incremental change that can be measured for time and 

— is expressed with a definite number of decimal digits or bits. 

localTime [0] LocalTimeStamp, 

utcTime [1] UTCTime 



LocalTimeStamp : : = SEQUENCE 


generalizedTime [0] GeneralizedTime, 


— The minimum resolution required is one second. 


— "Resolution" is the smallest incremental change that can be measured for time and 


— is expressed with a definite number of decimal digits or bits. 


winterSummerlndication [1] ENUMERATED 


notProvided(O) , 


winterTime ( 1 ) , 


summerTime ( 2 ) , 

} 
} 
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Partyinf ormation : : = SEQUENCE 

{ 

party-Qualifier [ ] ENUMERATED 

{ 

originating-Party ( ) , 

— In this case, the partylnformation parameter provides the identities related to 

— the originating party and all information provided by this party. 

— This parameter provides also all the information concerning the redirecting 

— party when a forwarded call reaches a target . 
terminating-Party ( 1 ) , 

— In this case, the partylnformation parameter provides the identities related to 

— the terminating party and all information provided by this party. 
f orwarded-to-Party ( 2 ) , 

— In this case, the partylnformation parameter provides the identities related to 

— the forwarded to party and parties beyond this one and all information 

— provided by this parties, including the call forwarding reason. 
gPRS-Target ( 3 ) , 

}, 

partyldentity [1] SEQUENCE 

{ 

imei [1] OCTET STRING (SIZE (8)) OPTIONAL, 

— See MAP format TS GSM 09.02 [32] 

tei [2] OCTET STRING (SIZE (1..15)) OPTIONAL, 

— ISDN-based Terminal Equipment Identity 

imsi [3] OCTET STRING (SIZE (3.. 8)) OPTIONAL, 

— See MAP format TS GSM 09.02 [32] International Mobile 

— Station Identity E.212 number beginning with Mobile Country Code 
callingPartyNumber [4] CallingPartyNumber OPTIONAL, 

— The calling party format is used to transmit the identity of a calling party 
calledPartyNiraiber [5] CalledPartyNumber OPTIONAL, 

— The called party format is used to transmit the identity of a called party or 

— a forwarded to party. 

msISDN [6] OCTET STRING (SIZE (1..9)) OPTIONAL, 

— MSISDN of the target, encoded in the same format as the AddressString 

— parameters defined in MAP format TS GSM 09.02 [32], clause 14.7.8. 

el64-Format [7] OCTET STRING (SIZE (1..25)) OPTIONAL, 

— E164 address of the node in international format. Coded in the same format as 

— the calling party number parameter of the ISUP (parameter part: EN 300 356 [5]) 
sip-uri [8] OCTET STRING OPTIONAL, 

— Session Initiation Protocol - Uniform Resource Identifier. See RFC 3261 [59] . 

— This parameter is duplicated from 3GPP TS 33.108 [61]. 
tel-url [9] OCTET STRING OPTIONAL 

— See "URLs for Telephone Calls", RFC 3966 [68] . 

— This parameter is duplicated from 3GPP TS 33.108 [61]. 
}, 

services-Information [2] Services-Information OPTIONAL, 

— This parameter is used to transmit all the information concerning the 

— complementary information associated to the basic call 
supplementary-Services-Inf ormation [3] Supplementary-Services OPTIONAL, 

— This parameter is used to transmit all the information concerning the 

— activation/invocation of supplementary services during a call or out-of call not 

— provided by the previous parameters . 
services-Data-Information [4] Services-Data-Information OPTIONAL, 

— This parameter is used to transmit all the information concerning the complementary 

— information associated to the basic data call. 



CallingP 

f 


artyNumber 




: : = 


CHOICE 




















iSUP 


-Format 




[1] 


OCTET STRING 


(SIZE 


(1. 


25)) 


^ 














— Encoded 


in 


the same format as 


the ca 


lling pa 


rty 


number 


(parameter 


field) 




— of the ISUP 


(see 


EN 300 356 [5] ) . 


















dSSl 


-Format 




[2] 


OCTET STRING 


(SIZE 


(1. 


25) ) 


, 














-- Encoded 


in 


the format defined 


for th 


e value 


part of the 


Calling 


part 


y number 




-- informat 


ion element of DSSl protocol 


EN 


300 


403- 


-1 [6]. 












— The DSSl 


Information element identif 


ier 


and 


the 


DSSl length are 


not 


included. 


mAP- 


Format 




[3] 


OCTET STRING 


(SIZE 


(1. 


25)) 














} 


— Encoded 


as 


AddressString of the MAP 


protocol 


TS 


GSM 09. 


02 [32]. 
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CalledPartyNumber 




: : = 


CHOICE 




















iSUP 


-Format 




[1] 


OCTET STRING 


(SIZE 


(1 


..25)), 
















— Encoded 


in 


the same format as 


the call 


ed party number 


(parameter 


fie 


Id) 






— of the ISUP (see 


EN 300 356 [5] ) . 


















mAP- 


Format 




[2] 


OCTET STRING 


(SIZE 


(1 


..25)), 
















— Encoded 


as 


AddressString of the MAP 


protocol TS 


GSM 


09 


.02 [32]. 








dSSl 


-Format 




[3] 


OCTET STRING 


(SIZE 


(1 


. .25) ), 
















— Encoded 


in 


the f 


3rmat defined 


for the 


value part of 


th 


2 Called p 


arty 


number in 


formation 




— element 


of 


DSSl protocol EN 300 403- 


1 


[6] . 














} 


— The DSSl Information element identifier and the 


DSSl 


1 


sngth are 


not 


included. 





Location : : = SEQUENCE 

; 




el64-Number 


[1] OCTET STRING (SIZE (1..25)) OPTIONAL, 




— Coded in 


the same format as the ISUP location number (parameter 




— field) of 


the ISUP (see EN 300 356 [5]). 




globalCelllD 


[2] OCTET STRING (SIZE (5.. 7)) OPTIONAL, 




— See MAP 


format (see TS GSM 09.02 [32]). 




tetraLocation 


[3] TetraLocation OPTIONAL, 




— This opt 


ional parameter is not in use anymore, but is kept for backwards compatibil 


ity. 


rAI 


[4] OCTET STRING (SIZE (6)) OPTIONAL, 




— The Rout 


eing Area Identifier (RAI) in the current SGSN is coded in accordance with 




— 3GPP TS 


24.008 [41] without the Routing Area Identification lEI (only the 




— last 6 octets are used) . 




gsmLo cation 


[5] GSMLocation OPTIONAL, 




umtsLocation 


[6] UMTSLocation OPTIONAL, 




sAI 


[7] OCTET STRING (SIZE (7)) OPTIONAL, 




— format: 


PLMN-ID 3 octets (no. 1-3), 




— 


LAC 2 octets (no. 4-5) , 




— 


SAC 2 octets (no. 6-7) 




— 


(according to 3GPP TS 25.431 [62]). 




oldRAI 


[8] OCTET STRING (SIZE (6)) OPTIONAL 




— the "Routeing Area Identifier" in the old SGSN is coded in accordance with 




— 3GPP TS 


24.008 [41] without the Routing Area Identification lEI 




— (only th 


e last 6 octets are used) . 




— This parameter is duplicated from 3GPP TS 33.108 [61]. 
} 





TetraLocation 


: := CHOICE 






— This optional parameter is not in use 


anymore. 


but is kept for backwards compatibility. 


ms-Loc 


[1] SEQUENCE 






mcc 


[1] INTEGER (0..1023), 






— 


10 bits EN 300 392-1 [40] 






mnc 


[2] INTEGER (0.. 16383), 






— 


14 bits EN 300 392-1 [40] 






lai 


[3] INTEGER (0.. 65535), 






— 


14 bits EN 300 392-1 [40] 






ci 


[4] INTEGER OPTIONAL 






Is-Loc 

} 


[2] INTEGER 
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GSMLocation ::= CHOICE 

{ 

geoCoordinates [ 1 ] SEQUENCE 
{ 

latitude [1] PrintableString (SIZE (7 . . 10) ) , 

— format: XDDI^IMSS.SS 

longitude [2] PrintableString (SIZE (8 . . 11) ) , 

— format: XDDDMMSS.SS 

mapDatum [3] MapDatum DEFAULT wGS84, 

azimuth [4] INTEGER (0..359) OPTIONAL 

— The azimuth is the bearing, relative to true north. 



format: XDDDMMSS.SS 



N(orth), S(outh), E(ast), W(est) 

degrees (numeric characters) 

minutes (numeric characters) 

seconds, the second part (.SS) is optional 



X 

DD or DDD 

MM 

SS.SS 

— Example : 

latitude short form N502312 

— longitude long form E1122312.18 

utmCoordinates [2] SEQUENCE 

{ 

utm-East [1] PrintableString (SIZE (10)), 
utm-North [2] PrintableString (SIZE (7)), 

— Universal Transverse Mercator 

— example utm-East 32U0439955 

utm-North 5540736 
mapDatum [3] MapDatum DEFAULT wGS84, 

azimuth [4] INTEGER (0..359) OPTIONAL 

— The azimuth is the bearing, relative to true north. 



utmRef Coordinates [ 3 ] SEQUENCE 

{ 

utmref-string PrintableString (SIZE (13) 

mapDatum MapDatum DEFAULT wGS84, 



— example 32UPU91294045 

wGS84Coordinates [4] OCTET STRING 

— format is as defined in 3GPP TS 03.32 [57] 



MapDatum : 


:= ENUMERATED 


WGS84, 




— 


World Geodetic System 1984 


WGS72, 




eD50, 




} 


European Datum 50 



UMTSLocation ::= CHOICE 

{ 

point [1] GA-Point, 

pointWithUnCertainty [2] GA-PointWithUnCertainty, 
polygon [3] GA-Polygon, 



GeographicalCoordinates : : = SEQUENCE 


latitudeSign 


ENUMERATED 


north. 




south 




latitude 


INTEGER (0. .8388607) , 


longitude 

} 


INTEGER (-8388608. .8388607) , 
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GA-Point : : = SEQUENCE 
{ 

geographicalCoordinates 



GeographicalCoordinates, 



GA-PointWithUnCertainty : : =SEQUENCE 



geographicalCoordinates 
uncertaintyCode 



GeographicalCoordinates^ 
INTEGER (0. . 127) 



maxNrOf Points 



INTEGER : := 15 



GA-Polygon ::= SEQUENCE (SIZE ( 1 . .maxNrOfPoints ) ) OF 
SEQUENCE 
{ 

geographicalCoordinates GeographicalCoordinates, 



CallContentLinkCharacteristics 



SEQUENCE 



cCLink-State [1] CCLink-State OPTIONAL, 

— current state of the CCLink 
release-Time [2] TimeStamp OPTIONAL, 

— date and time of the release of the Call Content Link. 
release-Reason [3] OCTET STRING (SIZE (2)) OPTIONAL, 

— Release cause coded in Q.850 [31] format. 
lEMF-Address [4] CalledPartyNumber OPTIONAL, 

— Directory number used to route the call toward the LEMF . 



CCLink-State 



ENUMERATED 



setUpInProcess (1) , 

— The set-up of the call is in process. 
callActive(2) , 

callReleased ( 3 ) , 
lack-of-resource (4) , 

— The lack-of-resource state is sent when a CC Link cannot 

— be established because of lack of resource at the MF level. 



Intercepted-Call-State : : = ENUMERATED 


idle ( 1 ) , 


— When the intercept call is released, the state is IDLE and the reason is provided 


— by the release-Reason-Of-Intercepted-Call parameter. 


setUpInProcess (2) , 


— The set-up of the call is in process. 


connected ( 3 ) , 


— The answer has been received. 

} 



Services-Information 


: : = 


SEQUENCE 


iSUP-parameters 


[1] 


ISUP-parameters OPTIONAL, 


dSSl-parameters-codeset-0 


[2] 


DSSl-parameters-codeset-0 OPTIONAL, 


mAP -parameters 

} 


[3] 


MAP-parameters OPTIONAL 
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ISUP-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "OCTET STRING" contains one additional ISUP parameter TLV coded not already defined in 

— the previous parameters. The Tag value is the one given in EN 300 356 [5] . 

— In version 1 of the present document "iSUP-parameters " is defined as mandatory. 

— It might occur that no ISUP parameter is available. In that case in a version 1 

— implementation the value "zero" may be included in the first octet string of the SET. 

— The Length and the Value are coded in accordance with the parameter definition in 

— EN 300 356 [5]. Hereafter are listed the main parameters. 

— However other parameters may be added: 

— Transmission medium requirement: format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the "calling party". 

— Transmission medium requirement prime: format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the "calling party". 



DSSl-parameters-codeset-0 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "OCTET STRING" contains one DSSl parameter of the codeset-0 . The parameter is coded as 

— described in EN 300 403-1 [6] (The DSSl Information element identifier and the DSSl length 

— are included) . Hereafter are listed the main parameters 

— (However other parameters may be added) : 

— Bearer capability: this parameter may be repeated. Format defined in EN 300 403-1 [6]. 

— This parameter can be provided with the "Party Information" of the "calling party", 

— "called party" or "forwarded to party". 

— High Layer Compatibility: this parameter may be repeated. Format defined in EN 300 403-1 [6] 

— This parameter can be provided with the "Party Information" of the "calling party", 

— "called party" or "forwarded to party". 

— Low Layer capability: this parameter may be repeated. Format defined in EN 300 403-1 [6]. 

— This parameter can be provided with the "Party Information" of the "calling party", 

— "called party" or "forwarded to party". 



MAP-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE ( 1 .. 256) ) 

— Each "OCTET STRING" contains one MAP parameter. The parameter is coded as described in 

— TS GSM 09.02 [32] (The map-TS-Code is included). 



Supplementary-Services 



SEQUENCE 



standard-Supplementary-Services [1] Standard- Supplementary- Services OPTIONAL, 
non-Standard-Supplementary— Services [2] Non- Standard- Supplementary- Services OPTIONAL, 
other-Services [3] Other-Services OPTIONAL, 



standard-Supplementary-Services 


: : = 


SEQUENCE 


iSUP-SS-parameters 


[1] 


ISUP-SS-parameters OPTIONAL, 


dSSl-SS-parameters-codeset-0 


[2] 


DSSI-SS-parameters-codeset-0 OPTIONAL, 


dSSl-SS-parameters-codeset-4 


[3] 


DSSl-SS-parameters-codeset-4 OPTIONAL, 


dSSl-SS-parameters-codeset-5 


[4] 


DSSl-SS-parameters-codeset-5 OPTIONAL, 


dSSl-SS-parameters-codeset-6 


[5] 


DSSl-SS-parameters-codeset-6 OPTIONAL, 


dSSl-SS-parameters-codeset-7 


[6] 


DSSl-SS-parameters-codeset-7 OPTIONAL, 


dSSl-SS-Invoke-components 


[7] 


DSSl-SS-Invoke-Components OPTIONAL, 


mAP-SS-Parameters 


[8] 


MAP-SS-Parameters OPTIONAL, 


mAP-SS-Invoke-Components 

} 


[9] 


MAP-SS-Invoke-Components OPTIONAL, 



Non- 


-Standard- 


-Supplementary- 


-Services : : = SET 


SIZE 


(1. 


.20) 


OF 


CHOICE 




simplelndication 


[1] 


Simple Indication, 










) 


sciData 




[2] 


SciDataMode 













Other-Services 



SET SIZE (1..50) OF OCTET STRING (SIZE (1..256) 



Reference manufacturer manuals . 
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ISUP-SS-parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— It must be noticed this parameter is retained for compatibility reasons. 

— It is recommended not to use it in new work but to use ISUP-parameters parameter. 

— Each "OCTET STRING" contains one additional ISUP parameter TLV coded not already defined in 

— the previous parameters. The Tag value is the one given in EN 300 356 [5] . 

— The Length and the Value are coded in accordance with the parameter definition in EN 300 356 [5] . 

— Hereafter are listed the main parameters. However other parameters may be added: 

— Connected Number: format defined in EN 300 356 [5] . 

— This parameter can be provided with the "Party Information" of the 

— "called party" or "forwarded to party". 

— RedirectingNumber : format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the "originating party". 

— Original Called Party Number: format defined in EN 300 356 [5] . 

— This parameter can be provided with the "Party Information" of the "originating party". 

— Redirection information: format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the 

— "originating party", "forwarded to party" or/and "Terminating party". 

— Redirection Number: format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the 

— "forwarded to party" or "Terminating party". 

— Call diversion information: format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the 

— "forwarded to party" or "Terminating party". 

— Generic Number: format defined in EN 300 356 [5] . 

— This parameter can be provided with the "Party Information" of the 

— "calling party", "called party" or "forwarded to party". 

— This parameters are used to transmit additional identities (additional, calling party 

— number, additional called number, ...) . 

— Generic Notification: format defined in EN 300 356 [5]. 

— This parameter may be provided with the "Party Information" of the 

— "calling party", "called party" or "forwarded to party". 

— This parameters transmit the notification to the other part of the call of the supplementary 

— services activated or invoked by a subscriber during the call. 

— cue Interlock Code: format defined in EN 300 356 [5]. 

— This parameter can be provided with the "Party Information" of the "calling party". 

DSSl-SS-parameters-codeset-0 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "OCTET STRING" contains one DSSl parameter of the codeset-0 . The parameter is coded as 

— described in EN 300 403-1 [6] (The DSSl Information element identifier and the DSSl length 

— are included) . Hereafter are listed the main parameters (However other parameters may be added) : 

— Calling Party Subaddress: format defined in EN 300 403-1 [6]. 

— This parameter can be provided with the "Party Information" of the "calling party". 

— Called Party Subaddress: format defined in EN 300 403-1 [6]. 

— This parameter can be provided with the "Party Information" of the "calling party". 

— Connected Subaddress: format defined in recommendation (see EN 300 097-1 [14]) . 

— This parameter can be provided with the "Party Information" of the 

— "called party" or "forwarded to party". 

— Connected Number: format defined in recommendation (see EN 300 097-1 [14]) . 

— This parameter can be provided with the "Party Information" of the 

— "called party" or "forwarded to party". 

— Keypad facility: format defined in EN 300 403-1 [6] . 

— This parameter can be provided with the "Party Information" of the 

— "calling party", "called party" or "forwarded to party". 

— Called Party Number: format defined in EN 300 403-1 [6] . 

— This parameter could be provided with the "Party Information" of the "calling party" 

— when target is the originating party; it contains the dialled digits before modification 

— at network level (e.g. IN interaction, translation, etc ...) . 

— User-user: format defined in EN 300 286-1 [23]). 

— This parameter can be provided with the "Party Information" of the 

— "calling party", "called party" or "forwarded to party". 
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DSSl-SS-parameters-codeset-4 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "OCTET STRING" contains one DSSl parameter of the cocleset-4 . The parameter is coded as 

— described in the relevant recommendation. 



DSSl-SS-parameters-codeset-5 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "OCTET STRING" contains one DSSl parameter of the codeset-5. The parameter is coded as 

— described in the relevant national recommendation. 



DSSl-SS-parameters-codeset-6 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "OCTET STRING" contains one DSSl parameter of the codeset-6. The parameter is coded as 

— described in the relevant local network recommendation. 



DSSl-SS-parameters-codeset-7 ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256)) 

— Each "octet string" contains one DSSl parameter of the codeset-7 . The parameter is coded as 

— described in the relevant user specific recommendation. 



DSSl-SS-Invoke-Con^Jonents : 


= SET SIZE 


(1. 


256) OF OCTET STRING (SIZE (1. 


256) ) 


— Each "octet string" contains one DSSl 


Invoke or Return Result component . 




— The 


invoke 


or 


return 


result 


component 


is coded as 




— described in the relevant DSSl supplementary service recommendation. 




— 


Invoke 


or 


Return 


Result 


component 


(BeginCONF) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(AddCONF) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(SplitCONF) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(DropCONF) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(IsolateCONF) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(ReattachCONF) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(PartyDISC) : EN 300 185-1 [19] 




— 


Invoke 


or 


Return 


Result 


component 


(MCIDRequest) : EN 300 130-1 [16] 




— 


Invoke 


or 


Return 


Result 


component 


(Begin3PTY) : EN 300 188-1 [20] 




— 


Invoke 


or 


Return 


Result 


component 


(End3PTY) : EN 300 188-1 [20] 




— 


Invoke 


or 


Return 


Result 


component 


(ECTExecute) : EN 300 369-1 [25] 




— 


Invoke 


or 


Return 


Result 


component 


(ECTInform) : EN 300 369-1 [25] 




— 


Invoke 


or 


Return 


Result 


component 


(ECTLinkldRequest) : EN 300 369-1 [25] 


— 


Invoke 


or 


Return 


Result 


component 


(ECTLoopTest) : EN 300 369-1 [25] 




— 


Invoke 


or 


Return 


Result 


component 


(ExplicitECTExecute) : EN 300 369-1 


[25] 


— 


Invoke 


or 


Return 


Result 


component 


(ECT: RequestSubaddress) : EN 300 369-1 [25] 


— 


Invoke 


or 


Return 


Result 


component 


(ECT: SubaddressTransfer) : EN 300 369-1 [25] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


ActivationDiversion) : EN 300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


DeactivationDiversion) : EN 300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


ActivationStatusNotif ication) 


EN 300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


DeactivationStatusNotification) : EN 300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


InterrogationDiversion) : EN 300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


Int errogati on ServedUser Number 


: EN 300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


Diversionlnformation) : EN 300 


207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


CallDeflection) : EN 300 207-1 


[21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


CallRerouteing) : EN 300 207-1 


[21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


DivertingLeglnformationl) : EN 


300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


DivertingLegInf ormation2 ) : EN 


300 207-1 [21] 


— 


Invoke 


or 


Return 


Result 


component 


(CF 


DivertingLegInf ormation3 ) : EN 


300 207-1 [21] 


— 


other invoke or return result componer 


Its ... 





MAP-SS-Invoke-Components ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1. 


.256) ) 


— Each "octet string" contains one MAP Invoke or Return Result component. 




— The invoke or return result component is coded as 




— described in the relevant MAP supplementary service recommendation. 





MAP-SS-Parameters ::= SET SIZE (1..256) OF OCTET STRING (SIZE (1..256); 

— Each "octet string" contains one MAP Parameter. The parameter is coded as 

— described in the relevant MAP supplementary service recommendation. 
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Simplelndication 


= ENUMERATED 


call-Waiting-Indication (0) , 






— The target has 


received a 


call waiting indication for this call 


add-conf-Indication ( 1 ) 








— this call has been added to a conference 


call-on-hold-Indication (2) , 






— indication that 


this 


call 


is on hold 


retrieve-Indication ( 3 ) 








— indication that 


this 


call 


has been retrieved 


suspend-Indication ( 4 ) , 








— indication that 


this 


call 


has been suspended 


resume-Indication ( 5 ) , 








— indication that 


this 


call 


has been resumed 


answer-Indication ( 6 ) , 








— indication that 
} 


this 


call 


has been answered 



SciDataMode ::= OCTET STRING (SIZE (1..256)) 



SMS-report : : = SEQUENCE 
{ 

communicationldentifier [1] Communicationldentif ier, 

— used to uniquely identify an intercepted call: the same used for the 

— relevant IRI 

— Called "callldentifier" in VI . 1 . 1 of ES 201 671 (see bibliography). 
timeStamp [2] Time St amp, 

— date and time of the report. The format is 

— the one defined in case a) of the ASN.l ITU-T Recommendation X.680 [33]. 

— (year month day hour minutes seconds) 
sMS-Contents [3] SEQUENCE 

{ 

initiator [ 1 ] ENUMERATED 

{ 

— party which sent the SMS 
target ( ) , 

server ( 1 ) , 
undefined-party (2 ) , 

}, 

transfer-status [2] ENUMERATED 

{ 

succeed-transf er ( ) , 

— the transfer of the SMS message succeeds 
not-succeed-transf er ( 1 ) , 
undefined (2) , 

} OPTIONAL, 

Other-message [3] ENUMERATED 

{ 

— In case of terminating call, indicates if the server will send other SMS. 
yes (0) , 

no(l), 
undefined (2) , 

} OPTIONAL, 

content [4] OCTET STRING (SIZE (1..270)) OPTIONAL, 

— Encoded in the format defined for the SMS mobile. 



Lawfullnterceptionldentifier : 


= OCTET STRING (SIZE 


(1. .25) ) 








— It is recommended to use ASCII 


characters in "a"..."z' 


, "A"..."Z", "-", " 


_" , " . " , and 


"0". 


."9". 


— For subaddress option only "0" 


.."9" shall be used. 











National-Parameters ::= SET SIZE (1..40) OF OCTET STRING (SIZE (1..256) 
— Content defined by national law. 



GPRSCorrelationNiraiber ::= OCTET STRING (SIZE (8 . . 20) ) 
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GPRSEvent 



ENUMERATED 



pDPContextActivation ( 1 ) , 

startOf InterceptionWithPDPContextActive (2) , 

pDPContextDeactivation (4) , 

gPRSAttach ( 5 ) , 

gPRSDetach ( 6 ) , 

cellOrRAUpdate ( 10 ) , 

sMS (11), 

pDPContextModif ication ( 13 ) 

see 3GPP TS 03.33 [42] 



Services-Data-Information : : = SEQUENCE 



gPRS-parameters 



[1] GPRS-parameters OPTIONAL, 



GPRS-parameters 



SEQUENCE 



pDP-address-allocated-to-the-target 

aPN 

pDP-type 



[1] DataNodeAddress OPTIONAL, 

[2] OCTET STRING ( SIZE ( 1 .. 100 ) ) OPTIONAL, 

[3] OCTET STRING (SIZE (2)) OPTIONAL, 



GPRSOperationErrorCode ::= OCTET STRING (SIZE (2)) 

— Refer to 3GPP TS 24.008 [41] for values (GMM cause or SM cause parameter) 



DataNodeAddress 



CHOICE 



ipAddress [1] IPAddress, 
x25Address [2] X25Address, 



IPAddress : : = SEQUENCE 


iP-type 


[ 1 ] ENUMERATED 


iPV4 ( ) , 




iPV6 ( 1 ) , 




}, 
iP-value 


[2] IP-value, 


iP-assignment 

{ 

static ( 1 ) , 


[3] ENUMERATED 




— The 


static coding shall be used to report a static address. 


dynamic ( 2 ) , 




— The 


dynamic coding shall be used to report a dynamically allocated address. 


notKnown ( 3 ) 


, 


— The 


notKnown coding shall be used to report other then static or dynamically 


— allocated IP addresses. 


} OPTIONAL, 

} 





IP-value 



CHOICE 



iPBinaryAddress [1] OCTET STRING (SIZE (4.. 16) 
iPTextAddress [2] lASString (SIZE (7. .45)), 



X25Address ::= OCTET STRING (SIZE (1.. 25) 
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National-HI2-ASNlparameters : := SEQUENCE 
{ 

countryCode [1] PrintableString (SIZE (2) ) , 

— Country Code according to ISO 3166-1 [67], 

— the country to which the parameters inserted after the extension marker apply. 

— In case a given country wants to use additional national parameters according to its law, 

— these national parameters should be defined using the ASN . 1 syntax and added after the 

— extension marker (...)■ 

— It is recommended that "version parameter" and "vendor identification parameter" are 

— included in the national parameters definition. Vendor identifications can be 

— retrieved from the lANA web site (see annex H) . Besides, it is recommended to avoid 

— using tags from 240 to 255 in a formal type definition. 



END — end of Hl20perations 



D.6 User data packet transfer (HIS CS) 

Declaration of ROSE operations "circuit-Call-related-Services" and "no-Circuit-Call-related-Services" are ROSE 
delivery mechanism specific. When using FTP delivery mechanism, data Content-Report must be considered. 

ASN.1 description of circuit data transfer operation (I-II3 interface) 

HISCircuitDataOperations 

{itu-t(O) identif ied-organization (4) etsi(O) securityDomain (2) lawfullntercept (2) hi3(2) 
circuitLI(l) versions (3)} 

DEFINITIONS IMPLICIT TAGS ::= 

— The following operations are used to transmit user data which can be exchanged via the DSSl, ISUP 

— or MAP signalling (e.g. UUS, SMS) . 

BEGIN 

IMPORTS OPERATION, 
ERROR 

FROM Remote-Ope rat ions -Information-Objects 

{ joint-iso-itu-t (2) remote-operations (4) informationOb jects (5) versionl(O)} 

— from clause D.5 

Lawfullnterceptionldentifier, 

Communicationlden'tifier, 

Time St amp, 

OperationErrors, 

Supplementary-Services , 

SMS-report 

FROM HI20perations 

{itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi2(l) 
versionlO (10) }; 



— Object Identifier definitions 

— Lawfullntercept Domainid 

lawfulInterceptDomainld OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4) etsi(C 
securityDomain (2) lawfullntercept (2) } 

— hi3 Domain 

hiSCircuitLIId OBJECT IDENTIFIER ::= { lawfulInterceptDomainld hi3 (2 ) circuitLI ( 1 ) } 
hiSCircuitLIOperationId OBJECT IDENTIFIER ::= (hiSCircuitLIId version3 (3 ) } 

circuit-Call-related-Services OPERATION ::= 
{ 

ARGUMENT Content-Report 
ERRORS {OperationErrors} 

CODE global: (hiSCircuitLIId circuit-Call-Serv ( 1 ) versionl(l)} 
} 

— Class 2 operation. The timer shall be set to a value between Ss and 240s. 

— The timer default value is 60s. 

— NOTE: The same note as for HI management operation applies. 
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no-Circuit-Call-related-Services OPERATION ::= 




ARGUMENT Content-Report 




ERRORS {OperationErrors} 




CODE global: (hiSCircuitLIId no-Circuit-Call-Serv (2 ) 


versionl (1) } 


— Class 2 operation. The timer must be set to a value between 


10s and 120s. 


— The timer default value is 60s. 





Content -Report : : = SEQUENCE 
{ 

domainID [0] OBJECT IDENTIFIER (hiSCircuitLIOperationId) OPTIONAL, 

— Once using FTP delivery mechanism 
lawfullnterceptionldentifier [6] Lawfullnterceptionldentif ier OPTIONAL, 
communicationldentifier [1] Communicationldentif ier, 

— Used to uniquely identify an intercepted call; the same as used for the relevant IRI . 

— Called "callldentifier" in VI . 1 . 1 of ES 201 671 (see bibliography). 
timeStamp [2] TimeStamp, 

initiator [3] ENUMERATED 

{ 

originating-party ( ) , 

terminating-party ( 1 ) , 

f orwarded-to-party ( 2 ) , 

undefined-party (3 ) , 

} OPTIONAL, 

content [4] Supplementary-Services OPTIONAL, 

— UUI are encoded in the format defined for the User-to-user information parameter 

— of the ISUP protocol (see EN 300 356 [5]) . Only one UUI parameter is sent per message. 
sMS-report [5] SMS-report OPTIONAL, 



END — end of HI3CircuitDataOperations 



D.7 TETRA data transfer (HIS interface) 

Clauses A.4.1.1, A.4.2.1 and A.9 apply. 

D.8 Definition of the UUS1 content associated to the CC 
link 

ASN.1 description of thie UUS1 content associated to thie CC linl< 

HISCCLinkData 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi3(2) cclinkLI(4) 
version4 (4 ) } 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 



IMPORTS 

— from clause D.5 
Lawfullnterceptionldentifier, 
Communicationldentifier, 
CC-Link-Identifier 

FROM HI20perations 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi2(l) 
versionlO (10) }; 



— Object Identifier Definitions 

— Lawfullntercept Domainid 

lawfulInterceptDomainld OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(O) 
securityDomain (2) lawfullntercept (2) } 
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— his Domain 

hiSCCLinkId OBJECT IDENTIFIER ::= { lawfulInterceptDomainld hi3 (2 ) ccLinkLI(4)} 

hiSCCLinkldOperationId OBJECT IDENTIFIER ::= (hiSCCLinkld version4 (4 ) } 



UUSl-Content 

{ 



SEQUENCE 



domainID [0] OBJECT IDENTIFIER (hiSCCLinkldOperationId) OPTIONAL, 

— Once using FTP delivery mechanism 
lawfulllnterceptionldentifier [1] Lawfullnterceptionldentif ier, 
communicationldentifier [2] Communicationldentif ier, 
cC-Link-Identifier [3] CC-Link-Identif ier OPTIONAL, 
direction-Indication [4] Direction-Indication, 
bearer-capability [5] OCTET STRING (SIZE (1 . . 12) ) OPTIONAL, 

— transport the Bearer capability information element (value part) 

— Protocol: EN 300 403-1 [6] 

service-Information [7] Service-Information OPTIONAL, 



— PARAMETERS FORMATS 



Direction-Indication : : = ENUMERATED 
{ 

mono-mode ( ) , 

cc-f rom-target ( 1 ) , 

cc-f rom-other-party ( 2 ) , 

direction-unknown ( 3 ) 



Service-Information 



SET 



high-layer-capability [0] OCTET STRING (SIZE(l) 

— HLC (octet 4 only) 

— Protocol: EN 300 403-1 [6] 

tMR [1] OCTET STRING (SIZE(l) 

— Transmission Medium Requirement 

— Protocol: ISUP EN 300 356 [5] 
bearerServiceCode [2] OCTET STRING (SIZE(l) 
teleServiceCode [3] OCTET STRING (SIZE(l) 



OPTIONAL, 



OPTIONAL, 



OPTIONAL, 
OPTIONAL 



from MAP, TS GSM 09.02 [32], clause 14.7.9 and clause 14.7.10 



END 



end of HI3CCLinkData 



D.9 Content of Communication (HIS GPRS) 

ASN.1 description of thie GPRS content 

Gprs-HI3-PS 

(itu-t(O) identif ied-organization (4 ) etsi(O) securityDomain (2) lawfullntercept (2) hi3(2) gPRSLI(3) 
version3 (3) } 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 



IMPORTS 








— from 3GPP TS 33.108 [61] 








CC-PDU 








FROM Umts-HI3-PS 








(itu-t (0) identified- organization (4) 


etsi (0) 


securityDomain (2) 


lawfullntercept (2) 


threeGPP(4) hi3(2) r7(7) version-0 ( ) } ; 
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— Object Identifier definitions 

— Lawfullntercept Domainid 

lawfulInterceptDomainld OBJECT IDENTIFIER ::= {itu-t(O) identif ied-organization (4 ) etsi(O) 
securityDomain (2) lawfullntercept (2) } 

— his Domain 

hiSGPRSLIId OBJECT IDENTIFIER ::= { lawfulInterceptDomainld hi3 (2 ) gPRSLI(3)} 
hiSGPRSLIIdOperationId OBJECT IDENTIFIER ::= (hiSGPRSLIId versions (3 ) } 

ETSI-CC-PDU : : = SEQUENCE 
{ 

domainID [0] OBJECT IDENTIFIER (hiSGPRSLIIdOperationId) OPTIONAL, 

— Once using FTP delivery mechanism 

eTSI-CC-PDU [1] CC-PDU, 



END — end of Gprs-HIS-PS 
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Annex E (informative): 

Use of subaddress and calling party number to carry 

correlation information 



E.1 Introduction 



Not all ISDN networks fully support the use of the UUSl service EN 300 286-1 [23]. Some networks may be limited to 
the transfer of only 32 octets of UUSl user information rather than the 128 required for full support of the UUSl 
service. Some networks may not support UUSl at all. 

This annex describes a procedure to provide correlation information which is appropriate: 

1) if a network does not support the delivery of UUS 1 ; or 

2) if a network does not support the delivery of 128 octets for UUS 1 . 

If all network involved support the delivery of 128 octets for UUSl then the procedure (described in this annex) is not 
appropriate. 

The calling party number, the calling party subaddress (CgP Sub) and the called party subaddress (CdP Sub) are used to 
carry correlation information. 



E.2 Subaddress options 

The coding of a subaddress information element is given in EN 300 403-1 [6]. The following options shall be chosen: 

Table E.2.1 : Subaddress options 



Option 


Value 


Type of subaddress 


user specified 


Odd/even indicator 


employed for called party subaddress when no national parameters are used 



E.3 Subaddress coding 

The coding of subaddress information shall be in accordance with EN 300 403-1 [6]. 

E.3.1 BCD values 

The values to 9 shall be BCD coded according to their natural binary values. The hexadecimal value F shall be used as 
a field separator. This coding is indicated in table E.3.1. 
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Table E.3.1 : Coding BCD values 



Item 


BCD representation 


Bit 4 


Bits 


Bit 2 


Biti 

















1 











1 


2 








1 





3 








1 


1 


4 





1 








5 





1 





1 


6 





1 


1 





7 





1 


1 


1 


8 


1 











9 


1 








1 


Field separator 


1 


1 


1 


1 



When items are packed two to an octet, the least significant item shall be coded by mapping bit 4 to bit 8, bit 3 to bit 7, 
etc. 

E.3.2 Field order and layout 

Fields shall be presented into the subaddress in the following order. 

Table E.3.2: Fields in the called party subaddress 



Order 


Field 


1 
2 
3 
4 


Operator- ID 

GIN 

CCLID 

National Parameters 



Table E.3.3: Fields in the calling party subaddress 



Order 


Field 


1 
2 
3 


Lawful Interception Identifier (LIID) 

Direction 

Service Octets 



Apart fi-om "National Parameters", inclusion and format of which is determined by national regulations, each field noted 
above shall be included, whether empty or not. Each of the Operator- ID, CIN, CCLID, LIID and Direction fields shall 
end by a field separator. 

When the sending entity does not have a valid value for either of Operator-ID, CIN, CCLID, LIID or Direction fields, 
then the field is considered empty and it shall be represented only by its field separator (see table E.3.6 as example of 
the Called party subaddress without the CIN parameter). 

The parameters within the Information Elements "Called Party Subaddress" and "Calling Party Subaddress" are 
variable. Because of this variable length the parameters may start in different octets in the related Information Element. 
I.e. in the Calling Party Subaddress the Direction can be found in octet 17 when the LIID is 25 digits long (table E.3.5). 

When the LIID is composed of less than 25 digits, the field separator and direction indicator "moves up" and the rest of 
the octets is spare till octet 19 as shown in table E.3.7. Between the last digit of the LIID and the Direction is always a 
Field separator (value F). Also after the "Direction" one Field Separator is given. The last Field separator separates the 
relevant data from the spare part. So the location of the TMR and the other service Octets below are fixed within the 
Subaddress. The total length of the Calling Party Subaddress is fixed to 23 octets (including the two Mobile service 
octets) or 21 octets (without the two Mobile service octets). 

The Service Octets as available shall always be mapped into octets 19 to 23 of the Calling Party Subaddress, as 
appropriate. If one of the parameters TMR, BC or HLC is not available, the octet shall be filled with "FF" hex. 
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In relation to Mobile Bearer Service Code and Mobile Teleservice Code, the mapping of the values into octets 22 and 
23, respectively, shall be done as follows: 

• if both. Mobile Bearer Service Code and Mobile Teleservice Code are provided by signalling, octets 22 and 
23, shall be present, each containing the mapped value; 

• if Mobile Bearer Service Code is provided by signalling, and Mobile Teleservice Code is NOT provided by 
signalling, octet 22 shall be present containing the mapped value, and octet 23 shall be omitted; 

• if Mobile Teleservice Code is provided by signalling, and Mobile Bearer Service Code is NOT provided by 
signalling, there are two implementation options: 

neither octet 22 nor octet 23 shall be present; 

octet 22 shall be filled with "FF" hex and octet 23 shall be present containing the mapped value; 

• if neither Mobile Teleservice Code nor Mobile Bearer Service Code is provided by signalling, neither octet 22 
nor octet 23 shall be present. 

As an option the Calling Party Subaddress and Called Party Subaddress may have a variable length. The length is given 
in octet 2. 

When the LIID is composed of less than 25 digits in the Calling Party Subaddress, the Field separator. Direction 
indicator. Field separator and all the Service Octets "moves up" as shown in table E.3.8. 

National Parameters in a variable length Called Party Subaddress may have variable length. 

Table E.3.4 represent called party subaddress and table E.3.5 calling party subaddress with the maximum length of the 
identifiers. 

Table E.3.4: Called party subaddress 



Bits 


Octets 


8 7 6 5 4 3 2 1 


Called party subaddress identifier 


1 
2 

3 

4 


Length of called party subaddress contents 


Type of subaddress = user specified, odd/even 


indicator 


Operator-ID ® 


Operator-ID ® 


Operator-ID ® 


Operator-ID ® 


5 


Field separator 


Operator-ID ® 


6 


GIN® 


GIN® 


7 


GIN® 


GIN® 


8 


GIN® 


GIN® 


9 


GIN® 


GIN® 


10 


GGLID ® 


Field separator 


11 


GGLID ® 


GGLID ® 


12 


GGLID ® 


GGLID ® 


13 


GGLID ® 


GGLID ® 


14 


Field separator 


GGLID ® 


15 
16 


(see note) 




17 




18 




19 




20 




21 




22 




23 


NOTE: The Octets after the final field (GGLID) 


of the Called 


Party Subaddress are reserved for nat 


onal use, e.g. for 


authentication purposes. 





£75/ 



94 



ETSI TS 101 671 V3.1.1 (2007-06) 



Table E.3.5: Calling party subaddress 



Bits 


Octets 


8 |7|6|5|4|3|2|1 


Calling party subaddress identifier 


1 
2 

3 

4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
18 
17 
18 

19 
20 
21 

22 

23 


Length of calling party subaddress contents 


Type of subaddress = user specified, odd/even 
indicator according to the amount of BCD-digits 


LIID® 

LIID® 

LIID® 

LIID® 
LIID®® 
LIID®® 
LIID®® 
LIID®® 
LIID®® 
LIID®® 
LIID®® 
LIID®® 
Field separator 
Field separator 


LIID® 

LIID® 

LIID® 

LIID® 

LIID® 

LIID®® 

LIID®® 

LIID®® 

LIID®® 

LIID®® 

LIID®® 

LIID®® 

LIID®® 

Direction 


spare 


spare 


ITU-T Recommendation Q.763 [48] TIVIR 
(see note 1) 


ITU-T Recommendation Q.931 BC [56] octet 3 
(see note 2) 


ITU-T Recommendation Q.931 HLC [56] 
octet 4 (see note 3) 


Mobile Bearer Service Code 
(see note 4) 


IVIobile Teleservice Code (see note 5) 


NOTE 1 : If available, the Transmission IVIedium Requirement 

according to EN 300 356 [5]. If not available, the value is 

"FF" hex. 
NOTE 2: If available, only octet 3 of the Bearer Capability 

i.e. according to EN 300 403-1 [6]. If not available, the 

value is "FF" hex. 
NOTE 3: If available, only octet 4 of the High Layer Compatibility 

i.e. according to EN 300 403-1 [6]. If not available, the 

value is "FF" hex. 
NOTE 4: If available, the Mobile Bearer Service Code according to 

TS GSM 09.02 [32], clause 14.7.10. If not available, the 

octets 22 and 23 (even if the mobile teleservice code is 

available) shall not be transmitted. 

If the mobile teleservice code is available optionally 

octet 22 could be filled with "FF" hex and be transmitted. 
NOTE 5: If available, the mobile teleservice code according to 

TS GSM 09.02 [32], clause 14.7.9. If not available, the 

octet 23 shall not be transmitted. 
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Table E.3.6: Example how field separator should be used when field is empty 
Called party subaddress without CIN parameter 



Bits 


Octets 


8 |7|6|5|4|3|2|1 


Called party subaddress Identifier 


1 
2 

3 

4 


Length of called party subaddress contents 


Type of subaddress = user specified, odd/even 


indicator 


Operator- ID ® 


Operator- ID ® 


Operator- ID ® 


Operator- ID ® 


5 


Field separator 


Operator- ID © 


6 


CCLID (D 


Field separator 


7 


CCLID (D 


CCLID ® 


8 


CCLID © 


CCLID ® 


9 


CCLID ® 


CCLID ® 


10 


Field separator 


CCLID ® 


11 


spare 


spare 


12 


spare 


spare 


13 


spare 


spare 


14 


spare 


spare 


15 
16 


(see note) 




17 




18 




19 




20 




21 




22 




23 


NOTE: The Octets after the final field (CCLID) 


of the Called 


Party Subaddress are reserved for na 


ional use, e.g. for 


authentication purposes. 





Tables E.3.7 and E.3.8 represent the Calling Party Subaddress containing an LIID with a length of only 5 octets. 
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Table E.3.7: Calling Party Subaddress 
(fixed length of 23 octets; example with LIID of only 5 digits) 



Bits 

8 76543 2 1 

Calling party subaddress identifier 

Length of calling party subaddress contents 
Type of subaddress = user specified, odd/even 
indicator according to the amount of BCD-digits 



LIID® 


LIID® 


LIID® 


LIID® 


Field separator 


LIID® 


Field separator 


Direction 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 


spare 



ITU-T Recommendation Q.763 [48] TIVIR 

(see note 1 ) 

ITU-T Recommendation Q.931 BC [56] 

octet 3 (see note 2) 

ITU-T Recommendation Q.931 HLC [56] 

octet 4 (see note 3) 

IVIobile Bearer Service Code 

(see note 4) 

IVIobile Teleservice Code (see note 5) 



Octets 

1 
2 



4 
5 
6 

7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 

19 

20 

21 

22 
23 



NOTE 1 : If available, the Transmission IVIedium Requirement 

according to EN 300 356 [5]. If not available, the value is 

"FF" hex. 
NOTE 2: If available, only octet 3 of the Bearer Capability 

i.e. according to EN 300 403-1 [6]. If not available, the value 

is "FF" hex. 
NOTE 3: If available, only octet 4 of the High Layer Compatibility 

i.e. according to EN 300 403-1 [6]. If not available, the value 

is "FF" hex. 
NOTE 4: If available, the IVIobile Bearer Service Code according to 

TS GSIVI 09.02 [32], clause 14.7.10. If not available, the 

octets 22 and 23 (even if the mobile teleservice code is 

available) shall not be transmitted. Optional octet 22 could be 

filled with "FF" hex and the IVIobile Teleservice Code be 

transmitted. 
NOTE 5: If available, the IVIobile Teleservice Code according to 

TS GSIVI 09.02 [32], clause 14.7.9. If not available, the octet 

23 shall not be transmitted. 
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Table E.3.8: Calling Party Subaddress 
(variable length; example with LIID of only 5 digits) 



Bits 

7 6 5 no 3 I 2 



Calling party subaddress identifier 


1 


Length of calling party subaddress contents 


2 


Type of subaddress = user specified, odd/even 
indicator according to the amount of BCD-digits 


3 


LIID® 

LIID® 
Field separator 
Field separator 


LIID® 

LIID® 

LIID® 

Direction 


4 
5 
6 

7 


spare (see note 6) 


spare (see note 6) 


8 


ITU-T Recommendation Q.763 [48] TIVIR 
(see note 1) 


9 



ITU-T Recommendation Q.931 BC [56] 

octet 3 (see note 2) 

ITU-T Recommendation Q.931 HLC [56] 
octet 4 (see note 3) 



IVIobile Bearer Service Code (see note 4) 



Octets 



10 

11 

12 
13 



IVIobile Teleservice Code (see note 5) 
NOTE 1 : If available, the Transmission Medium Requirement according to 

EN 300 356 [5]. If not available, the value is "FF" hex. 
NOTE 2: If available, only octet 3 of the Bearer Capability i.e. according to 

EN 300 403-1 [6]. If not available, the value is "FF" hex. 
NOTE 3: If available, only octet 4 of the High Layer Compatibility i.e. 

according to EN 300 403-1 [6]. If not available, the value is "FF" 

hex. 
NOTE 4: If available, the Mobile Bearer Service Code according to 

TS GSM 09.02 [32], clause 14.7.10. If not available, the octet 

(even if the mobile teleservice code is available) shall not be 

transmitted. 

Optional this octet could be filled with "FF" hex and the Mobile 

Teleservice Code be transmitted. 
NOTE 5: If available, the Mobile Teleservice Code according to 

TS GSM 09.02 [32], clause 14.7.9. If not available, the octet 

shall not be transmitted. 
NOTE 6: If the number of half octets for the LIID field and the direction 

field including the field separators is odd, then three half octets 

with the spare pattern "F" shall be included. 

If the number of half octets for the LIID field and the direction 

field including the field separators is even, then two half octets 
with the spare pattern "F" shall be included. 



E.4 Field coding 



Each field shall employ decimal coding, except for the Service Octets (octets 19-23 of the CgP Sub) and the octets 
reserved for national use (octets 16-23 of the CdP Sub). Other values are not permitted. 

E.4.1 Direction 

The direction field shall be coded as follows. 

Table E.4.1 : Direction coding 



Indication 


Value 


Mono mode (combined signal) (historic) 
CC from target 
CC to target 
Direction unknown 



1 
2 
3 
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E.4.2 Coding of the Calling Party Number 

The Network Element Identifier (NEID) shall be carried by the calling party number information element. The coding 
shall be as follows, depending on the type of network access (see note 1): 



Numbering plan 
identification: 

Nature of address: 



Type of number: 



Screening indicator: 
Screening indicator: 
Presentation indicator: 



ISDN/telephony numbering plan (ITU-T Recommendation E. 164 [58]). 

As specified in ITU-T Recommendation Q. 73 1.3 [63] (see note 1) (e.g. national (significant) 
number or international number) (in case of ISUP signalling). 

As specified in ITU-T Recommendation Q. 95 1.1 [64] and ITU-T Recommendation Q. 95 1.3 
[65], EN 300 092 [66] (e.g. unknown, subscriber number, national number or international 
number), and Network Operator specific type of access (BRA or PRA) (in case of DSSl 
signalling, see notes 2 and 3). 

Network provided (in case ISUP signalling). 

User-provided, not screened (in case of DSSl signalling, see note 3). 

Presentation allowed. 



NOTE 1 : The relevant national specification of the Signalling System Number 7 may also specify requirements on 
the Nature of address for national specific use in national variants of ISUP. 

NOTE 2: Usually, the IIF respectively the Mediation Function is connected to the network by links using Signalling 
System Number 7 and ISDN User Part (ISUP), whereby the parameters are coded according to 
EN 300 356 [5]. But in some cases, the IIF respectively the Mediation Function may be connected via a 
Basic Rate Access or a Primary Rate Access using D-Channel signalling, whereby the parameters are 
coded according to EN 300 403-1 [6]. 

NOTE 3: The network will perform screening, i.e. the number will arrive at the LEMF as "user-provided, verified 
and passed" with the appropriate "type of number" indicator. A network provided number is also accepted 
at the LEMF. 



E.5 Length of fields 



The length of the identifiers is variable. The maximum and recommended minimum length of each field is given in 
table E.5. 1. 

Table E.5.1 : Field length 



Fipid 


Minimum length 


Maximum length 


Maximum length 


1 F 




(decimal digits) 


(decimal digits) 


(Half-Octets) 




Operator ID 


2 


5 


5 + 1 


CdP Sub 


GIN 


6 


8 


8 + 1 


CdP Sub 


CCLID 


1 


8 


8+ 1 


CdP Sub 


LIID 


2 


25 


25 + 1 


CgPSub 


Direction 


1 


1 


1 +1 


CgP Sub 


Service Octets 






10 


CgPSub 
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Annex F (informative): 
GPRS HIS Interface 

F.1 Functional architecture 

Figure F.1.1 contains the reference configuration for lawful interception (see 3GPP TS 03.33 [42]). 



LEA 



NWO/AP/SvP's 

administration 

centre 




Figure F.1.1 : Reference configuration 

There is one ADMinistration Function (ADMF) in the network. Together with the delivery functions it is used to hide 
from the xGSN that there might be multiple activations by different Law Enforcement Agencies (LEAs) on the same 
target. 

NOTE: GGSN interception is a national option. 

The reference configuration is only a logical representation of the entities involved in lawful interception and does not 
mandate separate physical entities. This allows for higher levels of integration. 

A call could be intercepted based on several identities (MSISDN, IMSI, IMEI) of the same target. 

For the delivery of the CC and IRI the xGSN provides a correlation number and target identity to the DF2P and DF3P 
which is used there to select the different LEAs where CC/IRI shall be delivered to. 



F.2 Correlation 

Correlation of GSM IDs of 3GPP TS 03.33 [42] to the present document IDs. 
Warrant reference number -^ Lawful Interception IDentifier (LIID). 

xGSN address -^ Network IDentifier (NID). 

F.3 HIS Delivery Content of Communication (CC) 

There are two possible methods for delivery of Content of Communication to the LEMF: 

• GPRS LI Correlation (GLIC) Header and UDP/TCP (see clause F.3.1); 

• FTP/TCP (see clause F.3.2). 
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According to national requirements al least one of these methods have to be provided. 

However, when TCP is used as across the HI3, real time delivery of the result of the interception cannot be guaranteed. 
NOTE: Apart from transport layer protocol selection, real time delivery depends on network performance. 

F.3.1 GPRS LI correlation header 
F.3.1.1 Introduction 

The header and the payload of the communication between the intercepted subscriber and the other party (later called: 
Information Element) are duplicated. A new header (later called: GLIC -Header, see table F.3.1) is added 
(see table F.3.3) before it is sent to LEMF. 

Data packets with the GLIC header shall be sent to the LEA via UDP or TCP/IP. 

F.3.1 .2 Definition of GLIC header 

GLIC header contains the following attributes: 
correlation number; 

message type (a value of 255 is used for HI3-PDUs); 
direction; 
sequence number; 
length; 

GPRS Support Node (GSN) type. 
T-PDU contains the intercepted information. 

Table F.3.1 : Outline of GLIC header 





Bits 


Octets 


8 1 7 1 6 


5 


4 


3 


2 


1 


1 


Version ("0 0") 


"1" 


Spare 
"1" 


GSN 

type 


DIR 


"0" 














2 


Message Type (value 255) 


3-4 


Length 


5-6 


Sequence Number 


7-8 


not used (value 0) 


9 


not used (value 255) 


10 


not used (value 255) 


11 


not used (value 255) 


12 


not used (value 255) 


13-20 


correlation number 



For interception tunnelling the GLIC header shall be used as follows: 

• version shall be set to to indicate the first version of GLIC header; 

• DIR indicates the direction of the T-PDU: 

"1" indicating uplink (from observed mobile user); and 
"0" indicating downlink (to observed mobile user); 
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• message type shall be set to 255 (the unique value that is used for T-PDU within GTP (3GPP TS 09.60 [45]); 

• length shall be the length, in octets, of the signalling message excluding the GLIC header. Bit 8 of octet 3 is 
the most significant bit and bit 1 of octet 4 is the least significant bit of the length field; 

• sequence number is an increasing sequence number for tunnelled T-PDUs. Bit 8 of octet 5 is the most 
significant bit and bit 1 of octet 6 is the least significant bit of the sequence number field; 

NOTE: When a handoff occurs between SGSNs, the DF3 serving the LEA may change. If the DF3 serving an 
LEA changes as a result of an handoff between SGSNs, contiguous sequencing may not occur as new 
sequencing may be initiated at the new DF3. Accordingly, the LEA should not assume that sequencing is 
contiguous when handoff occurs between SGSNs and the DF3 serving the LEA changes. 

• correlation number consists of two parts: GGSN-ID identifies the GGSN which creates the Charging-ID: 

Charging-ID is defined in 3GPP TS 09.60 [45] and assigned uniquely to each PDP context activation on 
that GGSN (4 octets). 

The correlation number consists of 8 octets and guarantees a unique identification of the tunnel to the 
LEA over a long time. The requirements for this identification are similar to that defined for charging in 
3GPP TS 09.60 [45], clause 5.4. Therefore it is proposed to use the Charging-ID, defined in 
3GPP TS 09.60 [45], clause 5.4 as part of correlation number. The Charging-ID is signalled to the new 
SGSN in case of SGSN-change so the tunnel identifier could be used "seamlessly" for the HI3 interface. 

Table F.3.2: Outline of correlation number 
























1 




















2 




















3 









1 


2 


3 


4 


5 


6 


7 


8 


9 





1 


2 


3 


4 


5 


6 


7 


8 


9 





1 


2 


3 


4 


5 


6 


7 


8 


9 





1 




Charging-ID 
Octet 1 


Charging-ID 
Octet 2 


Charging-ID 
Octet 3 


Charging-ID 
Octet 4 


Octet 13 to 16 


GGSN-ID 


Octet 17 to 20 



The GLIC header is followed by a subsequent payload information element. Only one information element is allowed in 
a single signalling message. 

Table F.3.3: GLIC header followed by the subsequent payload 
Information Element (IE) 





Bits 


Octets 


8 


1 7 


1 6 1 5 1 4 1 3 


1 2 


1 1 


1-20 


GLIC- Header 


21-n 


Information Element 



• GPRS Support Node (GSN) type. Indicates whether the T-PDU was intercepted in the GGSN or in the SGSN: 
"0" indicating GGSN; and "1" indicating SGSN. 

This parameter is needed only in case the GGSN and the SGSN use the same Delivery Function/Mediation Function for 
the delivery of Content of Communication (CC). 

The Information Element (IE) contains the header and the payload of the communication between the intercepted 
subscriber and the other party. 

F.3.1.3 Exceptional procedure 

With UDP and GLIC: the delivering node does not take care about any problems at LEMF. 

With TCP and GLIC: TCP tries to establish a connection to LEMF and resending (buffering in the sending node) of 
packets is also supported by TCP. 

In both cases it might happen that call content gets lost (in case the LEMF or the transit network between MF and 
LEMF is down for a long time). 
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F.3.1.4 Other considerations 

The use of IPsec for this interface is recommended. 
The required functions in LEMF are: 

• Collecting and storing of the incoming packets inline with the sequence numbers. 

• Correlating of CC to IRI with the use of the correlation number in the GLIC header. 

F.3.2 FTP 
F.3.2.1 Introduction 

At HI3 interface FTP is used over the Internet protocol stack for the delivery of the result of interception. FTP is 
defined in RFC 959 [46]. The IP is defined in RFC 791 [51]. The TCP is defined in RFC 793 [52]. 

FTP supports reliable delivery of data. The data may be temporarily buffered in the sending node (MF) in case of link 
failure. FTP is independent of the payload data it carries. 

F.3.2.2 Usage of tine FTP 

In the packet data LI the MF acts as the FTP client and the receiving node (LEMF) acts as the FTP server. The client 
pushes the data to the server. 

The receiving node LEMF stores the received data as files. The sending entity (MF) may buffer files. 

Several smaller intercepted data units may be gathered to bigger packages prior to sending, to increase bandwidth 
efficiency. 

The following configurable intercept data collection (= transfer package closing/file change) threshold parameters 
should be supported: 

• frequency of transfer, based on send timeout, e.g. X ms; 

• frequency of transfer, based on volume trigger, e.g. X octets. 

There are two possible ways how the interception data may be sent from the MF to the LEMF. One way is to produce 
files that contain interception data only for one observed target (ref: "File naming method A)"). The other way is to 
multiplex all the intercepted data that MF receives to the same sequence of general purpose interception files sent by the 
MF (ref: "File naming method B)"). 

The HI2 and HI3 are logically different interfaces, even though in some installations the HI2 and HI3 packet streams 
might also be delivered via a common transmission path from a MF to a LEMF. It is possible to correlate HI2 and HI3 
packet streams by having common (referencing) data fields embedded in the IRI and the CC packet streams. 

File naming: 

The names for the files transferred to a LEA are formed according to one of the 2 available formats, depending on the 
delivery file strategy chosen (e.g. due to national convention or operator preference). 

Either each file contains data of only one observed target (as in method A) or several targets' data is put to files common 
to all observed target traffic through a particular MF node (as in method B). 

The maximum set of allowed characters in interception file names are "a"..."z", "A"..."Z", "-", "_", ".", and 
decimals "0"... "9". 

File naming method A): 
<LIID>_<seq>.<ext> 
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LIID = 



seq = 
ext = 



as defined in the present document. This field has a character string value, e.g. "ABCD123456". 
This is a unique interception request identifier allocated by the ADMF. It will be given by the 
ADMF to the LEA via the HIl interface after the ADMF has been authorized to command the start 
of the interception of a specific target. The possible network operator identifier part used should be 
agreed with (and allocated by) the regulatory organization administrating the local 
telecommunication practises. 

integer ranging between [0..2^4'l], in ASCII form (not exceeding 20 ASCII digits), identifying the 
sequence number for file transfer from this node per a specific target. 

ASCII integer ranging between ["1"..."8"] (in hex: 31H...38H), identifying the file type. The 
possible file type codings for intercepted data are shown in table F.3.4. The types "2", "4", and "6" 
are reserved for the HI3 interface and type "8" is reserved for data files according to a national 
requirement by using the same file naming concept. 



Table F.3.4: Possible file types 



File types that the LEA may get 


Intercepted data types 


"2" (in binary: 0011 0010) 


CC (MO) 


"4" (in binary: 0011 0100) 


CC (MT) 


"6" (in binary: 0011 0110) 


CC (MO&MT) 


"8" (in binary: 0011 1000) 


for national use 



The least significant bit that is "1" in file type 1, is reserved for indicating IRI data 

The bit 2 of the ext tells whether the Mobile Originated (MO) Content of Communication (CC) is included to the 
intercepted data. 

The bit 3 of the ext tells whether the Mobile Terminated (MT) Content of Communication (CC) is included to the 
intercepted data. 

The bit 4 of the ext tells whether the intercepted data is according to a national requirement. 

Thus, for Mobile Originated Content of Communication data, the file type is "2", for MT CC data "4", for MO&MT CC 
data "6" and for "national use" data the file type is "8". 

Thus, for Mobile Originated Content of Communication data, the file type is "2", for MT CC data "4" and for 
MO&MT CC data "6". 

This alternative A is used when each target's intercepted data is gathered per observed target to dedicated delivery files. 
This method provides the result of interception in a very refined form to the LEAs, but requires somewhat more 
resources in the sending node than alternative B. With this method, the data sorting and interpretation tasks of the 
LEMF are considerably easier to facilitate in near real time than in alternative B. 

File naming method B): 

The other choice is to use monolithic fixed format file names (with no trailing file type part in the file name): 

<filenamestring> of the format ABXYyymmddhhmmsseeeet 
where: 



AB = 
XY = 

yy = 

mm = 
dd = 
hh = 
mm = 

ss = 
eeee : 



t = 



Two letter ASCII Operator ID (as agreed with the national telecom regulators). 
Two letter ASCII identification of the MF node (as assigned by the operator). 



Two digits ASCII integer ranging between ["00". 
Two digits ASCII integer ranging between ["01". 
Two digits ASCII integer ranging between ["01". 
Two digits ASCII integer ranging between ["00". 
Two digits ASCII integer ranging between ["00". 
Two digits ASCII integer ranging between ["00". 



"99"] 

"12"] 
"31"] 
"23"] 
"59"] 



identifying the last to digits of the year, 
identifying the month, 
identifying the day. 
identifying the hour, 
identifying the minute. 



59"], identifying the second. 



Alphanumeric extension made up of four characters chosen at the discretion of the Operator and/or 
the MF to avoid file name clashes within the MF. Each of the position shall be out of "A"...."Z", 
"0"...."9" . 

ASCII integer ranging between ["1"...."8"] (in hex: 31H...38H), identifying the file type. The 
possible file type codings for intercepted data are shown in table F.3.4. 
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EXAMPLE: <filenamestring> (e.g. ABXY00041 014084400006) 
where: 

ABXY = Source node identifier part, used for all files by the mobile network operator "AB" from this MF 

node named "XY". 
00 = year 2000. 

04 = month April. 

10 = day 10. 

14 = hour. 

08 = minutes. 

44 = seconds. 

0000 = extension. 

6 = file type. Coding: "2" = CC (MO), "4" = CC (MT), "6" = CC (MO&MT), "8" = national use. 

(The type "1" is reserved for IRl data files.) 

This alternative B is used when several targets' intercepted data is gathered to common delivery files. This method does 
not provide the result of interception in as refined form to the LEAs as the alternative A, but it is faster in performance 
for the MF point of view. With this method, the MF does not need to keep many files open like in alternative A. 

F.3.2.3 Profiles 

NOTE: This clause is informative only. 

As there are several ways (usage profiles) how data transfer can be arranged by using the FTP, this clause contains 
practical considerations how the communications can be set up. Guidance is given for client-server arrangements, 
session establishments, time outs, the handling of the files (in RAM or disk). Example batch file is described for the 
case that the sending FTP client uses files. If instead (logical) files are sent directly from the client's RAM memory, 
then the procedure can be in principle similar though no script file would then be needed. 

At the LEMF side, FTP server process is run, and at MF, FTP client. No FTP server (which could be accessed from 
outside the operator network) shall run in the MF. The FTP client can be implemented in many ways, and here the FTP 
usage is presented with an example only. The FTP client can be implemented by a batch file or a file sender program 
that uses FTP via an API. The login needs to occur only once per e.g. <destaddr> and <leauser> - pair. Once the login is 
done, the files can then be transferred just by repeating "mput" command and checking the transfer status (e.g. from the 
API routine return value). To prevent inactivity timer triggering, a dummy command (e.g. "pwd") can be sent every 
T seconds (T should be less than L, the actual idle time limit). If the number of FTP connections is wanted to be as 
minimized as possible, the FTP file transfer method "B" is to be preferred to the method A (though the method A helps 
more the LEMF by pre-sorting the data sent). 

Simple example of a batch file extract: 

FTP commands usage scenario for transferring a list of files: 

To prevent FTP cmd line buffer overflow the best way is to use wildcarded file names, and let the FTP implementation 
do the file name expansion (instead of shell). The number of files for one mput is not limited this way: 

ftp <flags> <destaddr> 

user <leauser> <leapasswd> 

cd <destpath> 

led <srcpath> 

bin 

mput <files> 

nlist <lastfile> <checkfile> 

close 
EOF 

This set of commands opens an FTP connection to a LEA site, logs in with a given account (auto-login is disabled), 
transfers a list of files in binary mode, and checks the transfer status in a simplified way. 
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Brief descriptions for the FTP commands used in the example: 

user <user-name> <password> Identify the client to the remote FTP server. 

cd <remote-directory> Change the working directory on the remote machine to 

remote-directory . 
led <directory> Change the working directory on the local machine, 

bin Set the file transfer type to support binary image transfer 

mput <local-f iles> Expand wild cards in the list of local files given as 

arguments and do a put for each file in the resulting list. 

Store each local file on the remote machine, 
nlist <remote-directory> <local-file> Print a list of the files in a directory on the remote 

machine. Send the output to local-file, 
close Terminate the FTP session with the remote server, and return 

to the command interpreter. Any defined macros are erased. 

The parameters are as follows: 

<flags> contains the FTP command options, e.g. "-i -n -V -p" which equals to "interactive prompting off", "auto-login 
disabled", "verbose mode disabled", and "passive mode enabled". (These are dependent on the used ftp-version.) 

«lestaddr> contains the IP address or DNS address of the destination (LEA). 

<leauser> contains the receiving (LEA) username. 

<leapasswd> contains the receiving (LEA) user's password. 

<destpath> contains the destination path. 

<srcpath> contains the source path. 

<files> wild carded file specification (matching the files to be transferred). 

<lastfile> the name of the last file to be transferred. 

<checkfile> is a (local) file to be checked upon transfer completion; if it exists then the transfer is considered 

successful. 

The FTP application should to do the following things if the check file is not found: 

• keep the failed files; 

• raise "file transfer failure" error condition (i.e. send alarm to the corresponding LEA); 

• the data can be buffered for a time that the buffer size allows. If that would finally be exhausted, DF would 
start dropping the corresponding target's data until the transfer failure is fixed; 

• the transmission of the failed files is retried until the transfer eventually succeeds. Then the DF would again 
start collecting the data; 

• upon successful file transfer the sent files are deleted from the DF. 

The FTP server at LEMF shall not allow anonymous login of an FTP client. 

It is required that FTP implementation guarantees that LEMF will start processing data only after data transfer is 
complete. 

The following implementation example addresses a particular issue of FTP implementation. It is important however to 
highlight that there are multiple ways of addressing the problem in question, and therefore the given example does not 
in any way suggest being the default one. 

• MF sends data with a filename, which indicates that the file is temporary. Once data transfer is complete, MF 
renames temporary file into ordinary one (as defined in clause F.3.2.2). 

The procedure for renaming filename should be as follow: 

1) open FTP channel (if not already open) from MF to LEMF; 

2) sends data to LEMF using command "put" with temporary filename; 
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3) after MF finished to send the file, renaming it as ordinary one with command "ren". 

Brief descriptions for the FTP commands used in the example: 

ren <from-name> <to-name> renaming filename from-name to to-name. 

If the ftp-client want to send file to LEMF using the command "mput" (e.g. MF stored many IRI files and want 
to send all together with one command), every filename transferred successfully must be renamed each after 
command "mput" ended. 

F.3.2.4 Exceptional procedures 

Overflow at the receiving end (LEMF) is avoided due to the nature of the protocol. 

In case the transit network or receiving end system (LEMF) is down for a reasonably short time period, the local 
buffering at the MF will be sufficient as a delivery reliability backup procedure. 

In case the transit network or receiving end system (LEMF) is down for a very long period, the local buffering at the 
MF may have to be terminated. Then the following intercepted data coming from the intercepting nodes towards the MF 
would be discarded, until the transit network or LEMF is up and running again. 

F.3.2.5 CC contents for FTP 
F.3.2.5.1 Fields 

The logical contents of the CC-header are described here. 

CC-header = (Version, HeaderLength, PayloadLength, PayloadType, PayloadTimeStamp, PayloadDirection, 
CCSeqNumber, CorrelationNumber, LIID, PrivateExtension). 

The Information Element CorrelationNumber forms the means to correlate the IRI and CC of the communication 
session intercepted. 

The first column indicates whether the Information Element (IE) referred is Mandatory, Conditional or Optional. 

The second column is the Type in decimal. 

The third column is the length of the Value in octets. 

(Notation used in table F.3.5: M = Mandatory, O = Optional, C = Conditional.) 
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Table F.3.5: Information Elements in the fist version of the CC header 



Mode 


Type 


Length 


Value 


M 


130 


2 


Version = The version number of the format version to be used. This field has a decimal 
value, this enables version changes to the format version. The values are allocated 
according to national conventions. 





131 


2 


HeaderLength = Length of the CC-header up to the start of the payload in octets. 
(This field is optional since it is useful only in such cases that these information elements 
would be transferred without a dynamic length encapsulation that contains all the length 
information anyway. This field could be needed in case of e.g. adapting to a local 
encapsulation convention.) 





132 


2 


PayloadLength = Length of the payload following the CC-header. 
(This field is optional since it is useful only in such cases that these information elements 
would be transferred without a dynamic length encapsulation that contains all the length 
information anyway. This field could be needed in case of e.g. adapting to a local 
encapsulation convention.) 


M 


133 


1 


PayloadType = Type of the payload, indicating the type of the CC. Type of the payload. 
This field has a decimal value. The possible PDP Type values can be found in the 
standards, e.g. 3GPP TS 09.60 [45]. The value 255 is reserved for future PDP Types and 
means: "Other". 





134 


4 


PayloadTimeStamp = Payload timestamp according to intercepting node. (Precision: 1 s, 
timezone: UTC). Format: Seconds since 1970-01-01 as in e.g. Unix (length: 4 octets). 


C 


137 


1 


PayloadDirection = Direction of the payload data. This field has a decimal value if the 
payload data is going towards the target (i.e. downstream), or 1 if the payload data is being 
sent from the target (i.e. upstream). If this information is transferred otherwise, e.g. in the 
protocol header, this field is not required as mandatory. If the direction information is not 
available otherwise, it is mandatory to include it here in the CC header. 





141 


4 


CCSeqNumber = Identifies the sequence number of each CC packet during interception of 
the target. This field has a 32-bit value. 


M 


144 


8 or 20 


CorrelationNumber = Identifies an intercepted session of the observed target. This can be 
implemented by using e.g. the Charging Id (4 octets, see 3GPP TS 12.15 [49]) with the 
(4-octet/1 6-octet) Ipv4/lpv6 address of the PDP context maintaining GGSN node attached 
after the first 4 octets. 








<Possible future parameters are to be allocated between 145 and 253>. 





254 


1-25 


LIID = Field indicating the LIID as defined in the present document. This field has a 
character string value, e.g. "ABCD1 23456". 





255 


1-N 


PrivateExtension = An optional field. The optional Private Extension contains vendor or 
LEA or operator specific information. It is described in 3GPP TS 09.60 [45]. 
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Table F.3.6: Information Elements in the second version of the CC header 



Mode 


Type 


Length 


Value 


M 


130 


2 


Version = The version number of the format version to be used. This field has a decimal 
value, this enables version changes to the format version. The values are allocated according 
to national conventions. 





131 


2 


HeaderLength = Length of the CC-header up to the start of the payload in octets. 
(This field is optional since it is useful only in such cases that these information elements 
would be transferred without a dynamic length encapsulation that contains all the length 
information anyway. This field could be needed in case of e.g. adapting to a local 
encapsulation convention.) 





132 


2 


PayloadLength = Length of the payload following the CC-header in octets. 
(This field is optional since it is useful only in such cases that these information elements 
would be transferred without a dynamic length encapsulation that contains all the length 
information anyway. This field could be needed in case of e.g. adapting to a local 
encapsulation convention.) 


M 


133 


1 


PayloadType = Type of the payload, indicating the type of the CC. Type of the payload. This 
field has a decimal value. The possible PDP Type values can be found in the standards 
(e.g. 3GPP TS 29.060 [60]). The value 255 is reserved for future PDP Types and means: 
"Other". 





134 


4 


PayloadTimeStamp = Payload timestamp according to intercepting node. (Precision: 1 
second, timezone: UTC). Format: Seconds since 1970-01-01 as in e.g. Unix (length: 4 octets). 


C 


137 


1 


PayloadDirection = Direction of the payload data. This field has a decimal value if the 
payload data is going towards the target (i.e. downstream), or 1 if the payload data is being 
sent from the target (i.e. upstream). If this information is transferred otherwise, e.g. in the 
protocol header, this field is not required as mandatory. If the direction information is not 
available otherwise, it is mandatory to include it here in the CC header. 





141 


4 


CCSeqNumber = Identifies the sequence number of each CC packet during interception of 
the target. This field has a 32-bit value. 


M 


144 


8 or 20 


CorrelationNumber = Identifies an intercepted session of the observed target. This can be 
implemented by using e.g. the Charging Id (4 octets, see EN 300 097-1 [14]) with the 
(4-octet/1 6-octet) Ipv4/lpv6 address of the PDP context maintaining GGSN node attached 
after the first 4 octets. 








<Possible future parameters are to be allocated between 145 and 250> 


M 


251 


2 


MainElementID = Identifier for the TLV element that encompasses one or more 
HeaderElement-PayloadElement pairs for intercepted packets. 


M 


252 


2 


HeaderElementID = Identifier for the TLV element that encompasses the CC-header of a 
PayloadElement. 


M 


253 


2 


PayloadElementID = Identifier for the TLV element that encompasses one intercepted 
Payload packet. 





254 


1-25 


LIID = Field indicating the LIID as defined in the present document. This field has a character 
string value, e.g. "ABCD1 23456". 





255 


1-N 


PrivateExtension = An optional field. The optional Private Extension contains vendor or LEA 
or operator specific information. It is described in 3GPP TS 29.060 [60]. 



F. 3. 2.5. 2 Information Element syntax 

The dynamic TypeLength Value (TLV) format is used for its ease of implementation and good encoding and decoding 
performance. Subfield sizes: Type = 2 octets, Length = 2 octets and Value = 0. . .N octets. From Length the T and L 
subfields are excluded. The Type is different for every different field standardized. 

The octets in the Type and Length subfields are ordered in the little-endian order, (i.e. least significant octet first). Any 
multioctet Value subfield is also to be interpreted as being little-endian ordered (word/double word/long word) when it 
has a (hexadecimal 2/4/8-octet) numeric value, instead of being specified to have an ASCII character string value. This 
means that the least significant octet/word/double word is then sent before the more significant octet/word/double word. 

TLV encoding: 



Type (2 octets) 


Length (2 octets) 


Value (0-N octets) 
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TLV encoding can always be applied in a nested fashion for structured values. 



T 


L 


V 










T 


L 


V TLV TLV TLV TLV 













NOTE: The small "^" refers to the start of a Value field that has inside it a nested structure. 



In figure F.3.1, the TLV structure for GPRS HI3 transfer is presented for the case that there is just one intercepted 
packet inside the CC message. (There can be more CC Header IBs and CC Payload IBs in the CC, if there are more 
intercepted packets in the same CC message.) 



^ 




CC Information Element 


^: 


^ 






P: 


IVIainElementID 


CC Length 


CC 



(2 octets) 



(2 octets) 



(N octets) 



CC Header IE 



CC Payload IE 



HeaderElem.lD HeaderLength Header Value PayloadElem.lD PayloadLength 




Payload Value 



(2 octets) 



(2 octets) 



(N octets) 



(2 octets) ■ 



(2 octets) 



(N octets) 
Intercepted data packet 



^ 


Version IE 


" .■■' ^■- 


VersionID 


Length 


Version 



(2 octets) (2 octets) (2 octets) 



(The other lEs inside the CC Header 
Value field are here between) 



PrivateExtension IE 



PrivateExt.lD 



Length 



PrivateExtension 



(2 octets) 



(2 octets) 



(N octets) 



Figure F.3.1 : IE structure of a CC message that contains one intercepted packet 

The first octet of the first TLV element will start right after the last octet of the header of the protocol that is being used 
to carry the CC information. 

The first TLV element (i.e. the main TLV IB) comprises the whole dynamic length CC information, i.e. the dynamic 
length CC header and the dynamic length CC payload. 

Inside the main TLV IB there are at least 2 TLV elements: the Header of the payload and the Payload itself. The Header 
contains all the ancillary IBs related to the intercepted CC packet. The Payload contains the actual intercepted packet. 

There may be more than one intercepted packet in one GPRS HI3 delivery protocol message. If the Value of the main 
TLV IB is longer than the 2 (first) TLV Information Blements inside it, then it is an indication that there are more than 
one intercepted packets inside the main TLV IB (i.e. 4 or more TLV IBs in total). The number of TLV IBs in the main 
TLV IB is always even, since for every intercepted packet there is one TLV IB for header and one TLV IB for payload. 
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F.3.2.6 Other considerations 

The FTP protocol mode parameters used: 

• transmission mode: stream; 

• format: non-print; 

• structure: file-structure; 

• type: binary. 

The FTP service command to define the file system function at the server side: STORE mode for data transmission. 

The FTP client- (= user - FTP process at the MF) uses e.g. the default standard FTP ports 20 (for data connection) and 
21 (for control connection), "passive" mode is supported. The data transfer process listens the data port for a connection 
from a server-FTP process. 

For the file transfer from the MF to the LEMF(s) e.g. the following data transfer parameters are provided for the FTP 
client (at the MF): 

transfer destination (IP) address, e.g. "194.89.205.4"; 

transfer destination username, e.g. "LEAl"; 

transfer destination directory path, e.g. "/usr/local/LEAl/1234-829r'; 

transfer destination password; 

interception file type, e.g. "2" (this is needed only if the file naming method A is used). 

LEMF may use various kind directory structures for the reception of interception files. It is strongly recommended that 
at the LEMF machine the structure and access and modification rights of the storage directories are adjusted to prevent 
unwanted directory operations by a FTP client. 

The use of IPSec services for this interface is recommended. 



Timing considerations for tine FTP transmission: 

The MF and LEMF sides control the timers to ensure reliable, near-real time data transfer. The transmission related 
timers are defined within the lower layers of the used protocol and are out of scope of the present document. 

The following timers may be used within the LI application. 



Name 


Controlled by 


Units 


Description 


T1 inactivity timer 


LEMF 


Seconds 


Triggered by no activity within the FTP session (no new files). 
The FTP session is torn down when the T1 expires. To send 
another file the new connection will be established. The timer 
avoids the FTP session overflow at the LEMF side. 


T2 send file trigger 


MF 


Milliseconds 


Forces the file to be transmitted to the LEMF (even if the size 
limit has not been reached yet in case of volume trigger active). If 
the timer is set to the only trigger to send the file is the file size 
parameter (see clause C.2.2). 
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Annex G (informative): 

LEIVIF requirements - handling of unrecognized fields and 

parameters 

During decoding of a record at the LEA, the following exceptional situations may occur: 

1) Unrecognized parameter: The parameter layout can be recognized, but its name is not recognized: 
The parameter shall be ignored, the processing of the record proceeds. 

2) The parameter content or value is not recognized or not allowed: 

The parameter shall be ignored, the processing of the record proceeds. 

3) The record cannot be decoded (e.g. it seems to be corrupted): 

The whole record shall be rejected when using ROSE delivery mechanism or ignored. 

NOTE: In cases 2 and 3, the LEMF may wish to raise an alarm to the NWO/AP/SvP administration centre. For 
case 1, no special error or alarm procedures need be started at the LEA because the reason may be the 
introduction of a new version of the specification in the network, not be an error as such security aspects. 
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Annex H (informative): 

IP IVIultimedia Subsystem (IIVIS) handover 

This annex deals with IRI reporting in the IMS. IRI reporting in multi-media domain specified in this clause does not 
depend on the IP -Connectivity Access Network IP-CAN 3GPP TS 23.228 [70] used to transport the CC. When the 
IP -CAN is the UMTS PS domain, annex B applies for CC interception at the SGSN/GGSN. 

According to 3GPP TS 33.107 [71], interception has to be supported in P-CSCF and S-CSCF. For the identification of 
the intercepted traffic only the SIP-URL and TEL-URL are available. In the intercepting nodes (CSCFs) the relevant 
SIP -Messages are duplicated and forwarded to the MF HI2. 

For clarification see figure H.l. If P-CSCF and S-CSCF are in the same network the events are sent twice to the LEMF. 
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Figure H.1 : IRI Interception at a CSCF 



H.1 Specific identifiers for LI 



Specific identifiers are necessary to identify a target for interception uniquely and to correlate between the data, which 
is conveyed over the different handover interfaces (HI2 and HI3). The identifiers are defined in the clauses below. 

For the delivery of CC and IRI the SGSN, GGSN and CSCFs (Call Session Control Function) provide correlation 
numbers and target identities to the HI2 and HI3. The correlation number provided in the PS domain (SGSN, GGSN) is 
unique per PDP context and is used to correlate CC with IRI and the different IRJs of one PDP context. 

Interception is performed on an IMS identifier(s) associated with the intercept subject including identifiers such as 
SIP-URL and Tel-URL, RFC 3966 [68]. 
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H.1.1 Lawful interception identifier 



For each target identity related to an interception measure, the authorized operator (NO/AN/SP) shall assign a special 
LIID, which has been agreed between the LEA and the operator (NO/AN/SP). 

Using an indirect identification, pointing to a target identity makes it easier to keep the knowledge about a specific 
interception target limited within the authorized operator (NO/AN/SP) and the handling agents at the LEA. 

The LIID is a component of the CC delivery procedure and of the IRI records. It shall be used within any information 
exchanged at the handover interfaces HI2 and HI3 for identification and correlation purposes. 

The LIID format shall consist of alphanumeric characters. It might for example, among other information, contain a 
lawful authorization reference number, and the date, when the lawful authorization was issued. 

The authorized operator (NO/AN/SP) shall either enter, based on an agreement with each LEA, a unique LIID for each 
target identity of the interception subject or a single LIID for multiple target identities all pertaining to the same 
interception subject. 

Note that, in order to simplify the use of the LIID at LEMF for the purpose of correlating IMS signalling with GSN CC, 
the use of a single LIID in association with potentially numerous IMS identities (SIP and TEL URIs) is recommended. 

If more than one LEA intercepts the same target identity, there shall be unique LIIDs assigned relating to each LEA. 

In case the LIID of a given target has different values in the GSN and in the CSCF, it is up to the LEMF to recover the 
association between the two LIIDs. 



H.1 .2 Network identifier 



The network identifier (NID) is a mandatory parameter; it should be internationally unique. It consists of the following 
two identifiers. 

1) Operator- (NO/AN/SP) identifier (mandatory): 

Unique identification of network operator, access network provider or service provider. 

2) Network element identifier NEID (optional): 

The purpose of the network element identifier is to uniquely identify the relevant network element carrying out 
the LI operations, such as LI activation, IRI record sending, etc. 

A network element identifier may be an IP address or other identifier. 

H.1.3 Correlation number 

The GPRS Correlation Number is unique per PDP context and used for the following purposes: 

• correlate CC with GPRS Support Node (GSN) IRI; 

• correlate different GSN IRI records within one PDP context. 

As an example, in the UMTS system, the GPRS Correlation Number may be the combination of GGSN address and 
charging ID. 

NOTE 1 : It is an implementation matter how CSCF generates Correlation number value. However, in this release 
CSCF should use gPRSCorrelationNumber ASN.l parameter as a container. 

If two PDP contexts are used for the communication (one for signalling and one for bearer) also two correlation 
numbers may be delivered via the CSCFs. 
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Different identifiers may be used for correlating target's various SIP messages such as: 

• LIID; 

• implementation dependent number. 

NOTE 2: The implementation dependent number may be e.g. a "Call-id". However, when CSCF acts as a 
back-to-back user agent CSCF can have different "Call-id" values for different legs of signalling. 
Therefore some other number would be needed in such a case. 

NOTE 3: The LIID may be used to associate SIP messages with respective GSN IRI records. In case the target has 
a single SIP session active, the LIID is sufficient to correlate IMS IRI records with GSN IRI records. In 
case the target has multiple SIP sessions active, a combination of the LIID and an implementation 
dependent number may be used to correlate the IMS IRI records with the GSN IRI records. 

In case the LIID of a given target has different values in the GSN and in the CSCF, it is up to the LEMF to recover the 
association between the two LIIDs. 

SIP correlation number is used to correlate events of one specific SIP session. 

H.1.4 IRI for IMS 

In addition, information on non-transmission related actions of a target constitute IRI and is sent via HI2, 
e.g. information on subscriber controlled input. 

The IRI may be subdivided into the following categories: 

1) Control information for HI2 (e.g. correlation information). 

2) Basic data context information, for standard data transmission between two parties (e.g. SIP-message). 

For each event, a Record is sent to the LEMF, if this is required. The following table gives the mapping between event 
type received at DF2 level and record type sent to the LEMF. 

Table H.1.1 : Mapping between IMS Events and HI2 Records Type 



Event 


IRI Record Type 


SIP-Message 


REPORT 



A set of information is used to generate the record. The records used transmit the information from mediation function 
to LEMF. This set of information can be extended in the CSCF or DF2 MF, if new lEs are available and if this is 
necessary in a specific country. The following table gives the mapping between information received per event and 
information sent in records. 

Once IRI only interception is underway, LEMF receives IMS specific IRI only (SIP IRI) from CSCF. LEMF does not 
receive CC, and therefore it is not possible to correlate IMS specific IRI with CC. 

Once IRI and CC interception is underway, LEMF receives IMS specific IRI both from a GSN and from a CSCF. 
LEMF receives SIP messages also from a GSN within CC. In certain cases, however, SIP messages within CC may be 
encrypted between UE and CSCF. In these cases LEMF needs to receive unencrypted SIP IRI straight from CSCF. 



£75/ 



115 



ETSI TS 101 671 V3.1.1 (2007-06) 



Table H.I .2: Mapping between IMS Events Information and IRI Information 



Parameter 


Description 


HI2 ASN.1 parameter 


Observed SIP URI 


Observed SIP URI 


partylnformation (sip-uri) 


Observed TEL URL 


Observed TEL URL 


partylnformation (tel-url) 


Event type 


IIVIS Event 


iMSevent 


Event date 


Date of the event generation in the CSCF 


timeStamp 


Event time 


Time of the event generation in the CSCF 


Network identifier 


Unique number of the intercepting CSCF 


networkldentifier 


Correlation number 


Unique number for each PDP context delivered to the 
LEIVIF, to help the LEA, to have a correlation between 
each PDP Context and the IRI. Parameter of Rel. 5 and 
on 


gPRSCorrelationNumber 


Correlation 


Correlation number; unique number for each PDP 
context delivered to the LEIVIF, to help the LEA, to have 
a correlation between each PDP Context and the IRI. 
ASN.1 as: iri-to-CC 

Signalling PDP context correlation number; unique 
number for signalling PDP context delivered to the 
LEIVIF, to help the LEA, to have a correlation between 
each PDP Context and the IRI. 
Used in the case two PDP contexts are used. 
ASN.1 as: iri-to-CC 

SIP correlation number; either Call-id or some 
implementation dependent number that uniquely identify 
SIP messages of the same SIP session. 
ASN.1 as: iri-to-iri 


correlation 


Lawful interception 
identifier 


Unique number for each lawful authorization. 


lawful Interceptionldentifier 


SIP message 


Either whole SIP message, or SIP message header 
(plus SDP body, if any). SIP message header (plus 
SDP) is used if warrant requires only IRI. In such case, 
specific content in the SIPMessage (e.g. "IVIessage", 
etc.) must be deleted; unknown headers shall not be 
deleted. 


sIPMessage 



NOTE 1: LIID parameter is present in each record sent to the LEMF. 

NOTE 2: Details for the parameter SIP message. If the warrant requires only signalling information, specific 
content in the parameter "SIP message" like IMS (Immediate Messaging) has to be deleted/filtered. 

NOTE 3: In case of IMS event reporting, the gPRSCorrelationNumber HI2 ASN.1 parameter, which is also used in 
the IRIs coming from PS nodes, is used as container. 

H.1 .4.1 Events and information 

This clause describes the information sent from the Delivery Function (DF) to the Law Enforcement Monitoring 
Facility (LEMF) to support Lawfully Authorized Electronic Surveillance (LAES). The information is described as 
records and information carried by a record. This focus is on describing the information being transferred to the LEMF. 

The IRI events and data are encoded into records as defined in the table H.1.1 Mapping between IMS Events and HI2 
Records Type and clause B.3 Intercept related information (HI2). IRI is described in terms of a "causing event" and 
information associated with that event. Within each IRI Record there is a set of events and associated information 
elements to support the particular service. 

The communication events described in table H.1.1: Mapping between the IMS Event and HI2 Record Type and 
table H. 1 .2: Mapping between IMS Events Information and IRI Information convey the basic information for reporting 
the disposition of a communication. This clause describes those events and supporting information. 
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Each record described in this clause consists of a set of parameters. Each parameter is either: 

Mandatory (M): required for the record; 

Conditional (C): required in situations where a condition is met (the condition is given in the Description); or 

Optional (O): provided at the discretion of the implementation. 

The information to be carried by each parameter is identified. Both optional and conditional parameters are considered 
to be OPTIONAL syntactically in ASN.l Stage 3 descriptions. The Stage 2 inclusion takes precedence over Stage 3 
syntax. 

Table H.I. 3: SIP-Message REPORT Record 



Parameter 


MOC 


Description/Conditions 


observed SIP-URI 


C 


SIP URI of the interception target (if available). 


observed TEL-URL 


c 


TEL URL of the interception target (if available). 


event type 


M 


Provide IMS event type. 


event date 


M 


Provide the date and time the event is detected. 


event time 


network identifier 


M 


Shall be provided. 


lawful intercept identifier 


M 


Shall be provided. 


correlation number 





If available and not included in the SIP-message. 


correlation 





If applicable for this communication 


SIP message 


M 


The relevant SIP message or SIP message header. 



H.1 .5 Correlation indications of IIVIS IRI with GSN CC at the LEIVIF 

This clause is informative and provides some guidelines pertaining to correlating IMS IRI with GSN CC at the LEMF. 

For IMS-enabled multimedia communication scenarios involving a lawful intercept target, it will be necessary for the 
LEMF to be able to correlate the media streams (as provided in the CC intercepted by the GSN) with the specific SIP 
signalling (as provided in the IRI intercepted by the CSCFs) used to establish those media streams. The principal reason 
for this is that the Session Description Protocol (SDP) content within the SIP signalling may provide the information 
required to even be able to decode the media streams. In certain cases, for example, the information in the RTP header 
within the media stream packets may not be sufficient to be able to determine the specific encoding used. The SDP 
portion of the SIP signalling would need to provide this information. Another important reason is that the SIP signalling 
provides information about the participants in a SIP session (other than the target) sending and receiving the associated 
media streams. The LIID parameter in the IMS IRI and GSN CC can be used to correlating all of the IMS IRI and all of 
the GSN CC associated with a particular target. If a single LIID is used in association all of the target's IMS identities 
(as per a NO/AN/SP agreement with the LEA), the process of associating the IMS IRI and GSN CC information is 
fairly straightforward. If, however, multiple LIIDs are used (e.g. one per IMS identity) then the LEMF needs to be able 
to associate each of the LIIDs that may be used for the IMS IRI with the LIID used for the CC. 

The SIP messages provided to the LEMF would contain a number of additional items of information that could be 
relevant with respect to supporting correlations of various types. Their potential role in correlating IMS IRI and GSN 
CC (or, more specifically, correlating SIP dialogs with media streams) is discussed below: 

• Call-ID, From tag, To tag: These SIP headers would identify different SIP messages belonging to the same 
SIP dialog (a call leg between the target user and a peer SIP user). It should be noted that the Call-ID alone is 
not sufficient to identify a dialog. Correlating specific SIP dialogs with specific media streams is the principal 
objective of this discussion. 

• P-Charging- Vector (IMS Charging ID): The principal purpose of die IMS Charging ID (ICID) in IMS is to 
correlate charging information provided by different network entities for the same call. The ICID could be 
useful in correlating SIP messages belonging to the same call, even if their SIP dialog identifiers are modified 
(e.g. by a B2BUA application server). It should be noted, however, that the use of the ICID is not necessary 
for the purpose of correlating SIP dialogs and the corresponding media streams. 
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P-Charging- Vector (GPRS Charging ID, GGSN address): GCIDs, along with the GGSN address, may be 
used as identifiers of the PDP contexts. These identifiers (one for each PDP context used by the SIP session) 
are made available to the P-CSCF and subsequently to the S-CSCF. They could be used to correlate SIP 
messages with the PDP context(s) used. For the purpose of correlating SIP dialogs with media streams, this 
type of correlation would be useful, although not essential. 

SDP Connection addresses and ports: The address and port information within the SDP of the SIP messages 
need to be matched with the addresses and ports corresponding to the media streams as provided in the CC 
reports. This implies a need to look both at the SDP content of the SIP messages as well as in the packets 
provided by the GSN. The set of PDP context identifiers included in the P-Charging-Vector could be used to 
simplify the search for a match. It should also be noted that the SDP contained in the SIP message may also 
include essential information about the encoding of each of the media streams, without which it may not be 
possible to decode. 
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Annex I (informative): 

Latest ASN.1 module versions 



This annex is listing the ASN. 1 modules with the actual version numbers as defined in annex D. In case of any 
discrepancy the definitions given in annex D are the valid ones. This annex is just a summary of the ASN.l 
modules. TR 102 503 (see bibliography) gives a complete overview over the relevant Object Identifiers (OID) used 
in ASN.l modules of the Lawful Intercept specifications and point to the specification where the modules can be 
found. 

Defined in clause D.3: 



HIManagementOperations 

{itu-t(O) identified-organization (4) etsi(O) 

versions (3) ) 


securityDomain (2) 


lawfullntercept (2) 


him(3) 


Current version is 3. 
Defined in clause D.4: 


HIlNotificationOperations 

{itu-t(O) identified-organization (4) etsi(O) 

notificationOperations (1) versions (5) ) 


securityDomain (2) 


lawfullntercept (2) 


hil(O) 


Current version is 5. 
Defined in clause D.5: 


HI20perations 

{itu-t(O) identified-organization (4) etsi(O) 

versionlO(lO) ) 


securityDomain (2) 


lawfullntercept (2) 


hi2(l) 


Current version is 10. 
Defined in clause D.6: 


HISCircuitDataOperations 

{itu-t(O) identified-organization (4) etsi(O) 

circuitLI (1) versions (3) ) 


securityDomain (2) 


lawfullntercept (2) 


hi3(2) 


Current version is 3. 
Defined in clause D.7: 


EN301040 

{{itu-t(O) identified-organization (4) etsi(0 


en301040 (1040) intercept Version (0) ) ) 


Current version is 0. 
Defined in clause D.8: 


HISCCLinkData 

{itu-t(O) identified-organization (4) etsi(O) 

version4 (4) ) 


securityDomain (2) 


lawfullntercept (2) 


hi3(2) cclinlcLI(4) 


Current version is 4. 
Defined in clause D.9: 


Gprs-HI3-PS 

{itu-t(O) identified-organization (4) etsi(O) 

versions (3) ) 


securityDomain (2) 


lawfullntercept (2) 


hi3(2) gPRSLI(3) 



Current version is 3. 
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(CCBS) supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

ETSI EN 300 745-1: "Integrated Services Digital Network (ISDN); Message Waiting Indication (MWI) 
supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

ETSI EN 301 001-1 (Vl.2.2): "Integrated Services Digital Network (ISDN); Outgoing Call Barring (OCB) 
supplementary services; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1: Protocol specification". 

ETSI EN 301 065-1 (Vl.2.2): "Integrated Services Digital Network (ISDN); Completion of Calls on No Reply 
(CCNR) supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

ITU-T Recommendation Q.699: "Interworking between ISDN access and non-ISDN access over ISDN User 
Part of Signalling System No. 7". 

ITU-T Recommendation 1.210: "Principles of telecommunication services supported by an ISDN and the 
means to describe them". 

ISO 9798 (all parts): "Information technology - Security techniques - Entity authentication". 

ETSI EN 300 138-1: "Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary 
service; Digital Subscriber Signalling System No. one (DSSl) protocol; Part 1: Protocol specification". 
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IETF RFC 2228: "FTP Security Extensions". 

lANA Private Enterprise numbers: http://www.iana.org/assignments/enterprise-numbers . 

ETSI TS 123 003: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 
Telecommunications System (UMTS); Numbering, addressing and identification (3GPP TS 23.003)". 

ETSI TS 187 005: "Telecommunications and Internet converged Services and Protocols for Advanced 
Networking (TISPAN); NGN Lawful Interception; Functional entities, information flow and reference points". 

ITU-T Recommendation X.881: "Information technology - Remote Operations: OSI realizations - Remote 
Operations Service Element (ROSE) service definition". 

ETSI TR 102 503: "Lawful Interception (LI); ASN.l Object Identifiers in Lawful Interception Specifications". 

ETSI ETR 330: "Security Techniques Advisory Group (STAG); A guide to legislative and regulatory 
environment". 

ETSI ES 201 671: " Lawful Interception (LI); Handover interface for the lawful interception of 
telecommunications traffic". 
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Annex K (informative): 
Change Request history 



Status of the present document 
Handover interface for the lawful Interception of telecommunications traffic 


Date 


Version 


Remarks 


July 2001 


1.1.1 


TS version of ES 201 671 v2.1.1 (see note 1) 


December 2001 


2.2.1 


Included Change Requests: 

TS 101 671 CR001 (category D) on Removal of reference to TR 101 876 

TS 101 671 CR002 revi (category D) on Example on missing information 

TS 101 671 CR003 (category D) on Sending of IRI-END and IRI-CONTINUE records 

TS 101 671 CR004 (category D) on Moving GPRS related text from main body to 

annex B 

TS 101 671 CR005 revi (category F) on No additional work on HI1 interface port for 

administrative state 

TS 101 671 CR006 revi (category F) on Version indication 

TS 101 671 CR007 revi (category F) on No additional identifiers for Pacl<et switched 

networl< handover 

TS 101 671 CR008 rev2 (category D) on Several editorials 

TS 1 01 671 CR009 (category F) on UUS1 -parameter no. 6: "bearer capability of target 

call" 

TS 101 671 CR010 revi (category D) on Modification of the definition "CC linl<" 

TS 101 671 CR01 1 (category D) on Modification of the definition "Internal Network 

Interface": change "mediation device" into "mediation function" 

TS 101 671 CR013 (category D) on Deletion of the definition "mediation device" 

all CRs approved by SEC-LI#31 (27-29 November 2001 ; Wien) 
version 2.2.1 prepared by Peter van der Arend (KPN) (rapporteur) 


April 2002 


2.3.1 


Included Change Requests: 

TS 101 671 CR014 rev 2 (cat F) on annex E, Coding of the Calling Party Number 

TS 101 671 CR015 rev 2 (cat F) on clause D.5 Coordinates 

TS 101 671 CR016 (cat C) on clause D.5 - Exports Capabilities 

TS 101 671 CR017 rev 1 (cat D) on clause C.2.2 - File naming method B; clause F.3.2.2 

- File naming method B 

TS 101 671 CR018 rev 1 (cat C) on clause D.5 - TimeStamp 

TS 101 671 CR019 (cat F) on Correction of superfluous spaces in ASN.1 coding 

TS 101 671 CR021 (cat D) on Reintroduction of deleted references 

TS 101 671 CR022 rev 2 (cat F) on Aligning ETSI TS 101 671 with 3GPP 

TS 33.108 [61] 

TS 101 671 CR025 (cat F) on Correction of Misalignment between the text and the 

ASN.1 

all CRs approved by SEC-LI#32 (19-21 March 2002, Sophia Antipolis) 
version 2.3.1 prepared by Peter van der Arend (KPN) (rapporteur) 


June 2002 


2.4.1 


Included Change Requests: 

TS 101 671 CR026 (cat F) on Correcting "ccitt" into "itu-t" in ASN.1 Object Tree 

TS 101 671 CR027 rev 1 (cat C) on Missing ISUP parameter in version 1 

TS 101 671 CR028 rev 1 (cat B) on Use of the object identifier within the IRI 

TS 101 671 CR030 rev 1 (cat B) on Extension/alignment of ASN.1 module with 33.108 

TS 101 671 CR031 (cat F) on Missing/old reference 

TS 101 671 CR032 rev 2 (cat B) on ASN.1 alignment with the UMTS module 

TS 101 671 CR033 (cat B) on Adding a graphical ASN.1- Object tree 

all CRs approved by SEC-LI#33 (18-20 June 2002, Sophia Antipolis); 
version 2.4.1 prepared by Peter van der Arend (KPN) (rapporteur) 


October 2002 


2.5.1 


Included Change Requests: 

TS 101 671 CR034 rev 1 (cat B) on Aggregation of IRI Records 

TS 101 671 CR036 (cat F) on ASN.1 version number 

TS 101 671 CR037 rev 1 (cat F) on Missing pDPContextModification parameter 

TS 101 671 CR038 rev 1 (cat F) on Missing ggsnAddress parameter 

all CRs approved byTC Ll#01 (15-17 October 2002, Dublin); 
version 2.5.1 prepared by Peter van der Arend (KPN) (rapporteur) 
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Status of the present document 
Handover interface for the lawful interception of telecommunications traffic 


Date 


Version 


Remarks 






Including editorial modifications by ETSI 


March 2003 


2.6.1 


Included Change Requests: 

TS 101 671 CR035 (cat F) on Coding of ASN.1 parameters of the type OCTET STRING 

TS 101 671 CR039r1 (cat C) on Composition of calling Party Subaddress 

TS 101 671 CR041 (cat C) on Additional value direction indication (PARTLY) 

TS 101 671 CR042r2 (cat F) on Data Link Establishment and Sending part for ROSE 

operation 

TS101671 CR043r1 (cat C) on Clarification of definitions of sequence number and 

communication identity number 

TS 101 671 CR045 (cat C) on HI3 delivery of CC 

TS 101 671 CR046r1 (cat D) on Field separator in subaddress 

TS 101 671 CR047r1 (cat F) on Essential correction to the LI events generated during 

RAU when PDP context is active 

TS 101 671 CR048r2 (cat F) on Adjustments to the requirements on the delivery of the 

intercepted RT data over TCP 

all CRs approved by TC Ll#02 (4-6 March 2003, Benalmadena); 

See Note 2. 

TS 101 671 CR044r1 (cat C) on Additional value antenna direction GSM location 

information 

TS 101 671 CR049 (cat C) on CallingPartyNumber and mAP-Format 

version 2.6.1 prepared by Peter van der Arend (KPN) (rapporteur) 


June 2003 


2.7.1 


agreed CRs in TC Ll#02: 049, 041 (partly) were put on hold because of changes to 
ASN.1 and these ASN.1 parts are included now (CRs 044r1 was modified): 
TS 101 671 CR041 (cat C) on Additional value direction indication (PARTLY) 
TS 101 671 CR049 (cat C) on CallingPartyNumber and mAP-Format 

Included Change Requests: 

TS 101 671 CR044r3 (cat C) on Additional value antenna direction GSM location 

information 

TS 101 671 CR050 (cat C) on Precision about Services-Information field 

TS 101 671 CR051 (cat F) on Use of identifiers, elimination of "CC only" delivery option 

these CRs were approved by TC Ll#03 (3-5 June 2003, Copenhagen); 

Involved ASN.1 modules: 
HI20perations ->v4 
HI3CCLinkData ->v3 

version 2.7.1 prepared by Peter van der Arend (KPN) (rapporteur) 


October 2003 


2.8.1 


Included Change Request: 

TS 101 671CR052r1 (cat F) on Inconsistency regarding definition of CIN length 

this CR was approved by TC Ll#04 (14-16 October 2003, Moscow); 

version 2.8.1 prepared by Peter van der Arend (KPN) (rapporteur) 


March 2004 


2.9.1 


Included Change Request: 

TS 101 671 CR054 (cat D) Editorials to clause C.I. 2.1 

TS 101 671 CR055 (cat D) Removal of superfluous spaces from ASN.1 description 

TS 101 671 CR056r2 (cat B) Introduction of national parameters in the him module 

TS 101 671 CR058r1 (cat B) Introduction of national ASN.1 coded parameters in HI2 

TS 101 671 CR059 (cat D) Correction of the Routing Area Identifier 

TS 101 671 CR060 (cat D) Correction of wrong use of abbreviations 

TS 101 671 CR061 (cat D) Alignment names of RO-operations 

TS 101 671 CR062r1 (cat B) Decoding HI1 Notification and HI2 IRI-Parameters h 1 P file 

TS 101 671 CR063r1 (cat F) WGS 84 Coordinates updates 

TS 101 671 CR064r2 (cat D) Editorial corrections to CS domain 

TS 101 671 CR065 (cat F) Correction to the reference for Called Party Number 

TS 101 671 CR066r2 (cat C) Field separator in subaddress 

TS 101 671 CR068 (cat F) No SMS content in case of IRI only 

TS 101 671 CR069r3 (cat F) Correction of the Subaddressing definitions 

These CRs were approved by TC Ll#05 (23-25 March 2004, Oxford); 

version 2.9.1 prepared by Peter van der Arend (KPN) (rapporteur) 
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Status of the present document 
Handover interface for the lawful Interception of telecommunications traffic 


Date 


Version 


Remarks 


July 2004 


2.10.1 


Included Change Request: 

TS 101 671CR072r4 (cat B) Extensions to the "National-HI2-ASN1 parameters" data 

type 

TS 101 671CR073r1 (cat D) Clarifying clause titles 

TS 101 671CR076r2 (cat F) References in TS 101 671 

TS 101 671CR077 (cat B) Nature of the intercepted call 

TS 101 671CR078 (cat F) Served User for CLIP and COLP and other minor correction 

TS 101 671CR079r4 (cat B) Importing CC definition for PS domain from 3GPP module 

TS 101 671CR080r1 (cat D) Spare Octets in the Subaddress in annex E 

TS 101 671CR081 (cat D) ed correction of parameter name "setUplnProcess" 

These CRs were approved by TC Ll#06 (22-23 July, Povoa de Varzim); 

version 2.10.1 prepared by Peter van der Arend (KPN) (rapporteur) 


September 2004 


2.11.1 


Included Change Request: 

TS 101 671 CR082r1 (cat B) Addition of HI2 via to transfer UUS information 

TS 101 671 CR083 (cat D) Explanation concerning the Sequence Number 

TS 101 671 CR084r1 (cat D) Format of the CIN and CC-Link-ldentifier 

TS 101 671 CR085 (cat C) Addition of the domainID in the parameter "National-HII- 

ASN1" parameters 

TS 101 671 CR086 (cat C) Addition of the Lawful Interception Identifier in the parameter 

"Alarm-Indicator" 

TS 101 671 CR087 (cat D) New annex listing latest ASN.1 module versions in 

TS101 671 

TS 101671 CR088 (cat D) PDP Context modification request 

TS101 671 CR089r2 (cat B) Aligning "IRI-Parameters" with those defined in 

3GPPTS 33.108 [61] 

TS 101 671 CR090 (cat B) Interception of fixed NGN (including PSTN/ISDN emulation) 

and fixed IMS PSTN simulation 

Alignment of latest ASN.1 version of the imported ASN.1 modules 

These CRs were approved by TC Ll#07 (28-30 September 2004, Bremen); 

version 2.1 1 .1 prepared by Peter van der Arend (KPN) (rapporteur) 


February 2005 
June 2005 


2.12.1 


Included Change Request: 

TS 101 671CR091r2 (cat B) Support of TS 101 909-20 [69] Sub-Part 1 LI parameters 
TS 1 01 671 CR092 (cat F) Correction to GLIC header - Alignment with 
3GPPTS 33.108 [61] 

TS101671CR093 (cat F) References in TS 101 671 
These CRs were approved by TC Ll#08 (22-24 February 2005, Kijkduin); 

TS 101 671CR095 (cat C) Removing the SecurityDomainDefinitions in clause D.2. 

TS 101 671CR096r3 (cat D) Clarification of requirement to assign CIN values by 

relevant network element 

TS 101 671CR097r2 (cat D) Clarification of requirement to provide full IRI for intercepted 

SIVIS messages, even if some of the information is embedded in the SIVIS message body 

(IRI for SMS) 

TS101671CR098 (cat F) Updating imports statement for ASN.1 definition of the ULICvl 

header 

TS 1 01 671 CR099r1 (cat F) Alignment CR for IMS LI 

TS 101 671CR100r2 (cat C) Freezing "IRIversion" parameter In ASN.1 module 

TS 101 671CR102r1 (cat D) Resolution 

TS 101 671CR103 (cat B) New parameters defined in3GPP TS 33.108 [61] 

These CRs were approved by TC Ll#09 (28-30 June 2005, Rovaniemi) 

See note 3. 

version 2.12.1 prepared by Peter van der Arend (KPN) (rapporteur) 


October 2005 


2.13.1 


Included Change Request: 

TS 101 671 CRIOIrl (cat C) Aligning LIID definitions 

TS 101 671 CR105 (cat D) Informative example of h 1 P implementation across HI2/HI3 

These CRs were approved by TC Ll#1 (4-6 October 2005, Sorrento 

See note 4. 

version 2.13.1 prepared by Peter van der Arend (KPN) (rapporteur) 
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Status of the present document 
Handover interface for the lawful interception of telecommunications traffic 


Date 


Version 


Remarks 


February 2006 


2.14.1 


Included Change Request: 

TS 101 671 CR104r3 (cat C) Extending table C.2.1 and table F.3.4 for national use 

TS 101 671 CR106r1 (cat D) Explanation on Open Issues 

TS 101 671 CR107 (cat F) Correction on polygon type of shape 

TS 101 671 CR109 (cat F) Handling of unknown SIP headers 

TS101 671 CRIIOrl (cat F) TETRA finalization 

TS 101 671 CR1 1 1 (cat F) Re-correcting changes made during publication process 

These CRs were approved by TC Ll#1 1 (30 January - 1 February 2006, Saint Martin. 

See note 5. 

version 2.14.1 prepared by Peter van der Arend (KPN) (rapporteur) 


September 2006 


2.15.1 


Included Change Request: 

TS 101 671 CRIOSrI (cat B) TISPAN NGN PSTN Emulation Service and PSTN 

Simulation Service Stage 3 description 

TS 1 01 671 CR1 1 1 2r1 (cat D) Modifications as requested by ETSI EditHelp 

These CRs were approved by TC Ll#13 (6-8 September 2006 in Stockholm. 

See note 6. 

version 2.15.1 prepared by Peter van der Arend (KPN) (rapporteur) 


June 2007 


3.1.1 


TS version of ES 201 671 V3.1 .1 (see bibliography) as basis for further work 


NOTE 1 : The V1 .1 .1 of the TS should also have been V2.1 .1 (PvdA). 

NOTE 2: Agreed CRs 044r1 , 049, 041 (partly) are put on hold because of changes to ASN.1 and will be included in a 

next version if the specification. 
NOTE 3: Rapporteur: The new imported ASN.1 elements related to the nonpublished versions of 

TS 101 909-20-1 [69]and3GPPTS33.108 R7 are put on hold and will be included later in V2.1 3.1. 
NOTE 4: The new imported ASN.1 elements related to the non published versions of TS 101 909-20-1 [69] are still 

not included and put on hold and will be included later in V2.14.1. The imported parameters from 

3GPP TS 33.108 [61] R7 are included now in V2.13.1. 
NOTE 5: In V2.14.1 the ASN.1 parameter imported from TS 101 909 20 01 [69] is included now. 
NOTE 6: V2.15.1 is the basis for Edtion 3 (v3.1.1) of ES 201 671 (see bibliography) 
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History 


Document history 


VI. 1.1 


July 1999 


Publication as ES 201 671 first Edition 


VI. 1.1 


July 2001 


Publication 


V2.1.1 


September 2001 


Publication as ES 201 671 second Edition 


V2.5.0 


November 2002 


Publication (Withdrawn) 


V2.5.1 


January 2003 


Publication 


V2.7.1 


September 2003 


Publication 


V2.8.1 


November 2003 


Publication 


V2.9.1 


May 2004 


Publication 


V2.10.1 


September 2004 


Publication 


V2.11.1 


November 2004 


Publication 


V2.12.1 


August 2005 


Publication 


V2.13.1 


January 2006 


Publication 


V2.14.1 


May 2006 


Publication 


V2.15.1 


November 2006 


Publication 


V3.1.1 


May 2007 


Publication as ES 201 671 third Edition 


V3.1.1 


June 2007 


Publication 
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